Exchange 2007 SP3, Rollup 7 We're migrating one of our Exchange servers to new hardware. The old server has CAS, HUB, UM, and MBX rolls. We already had a separate dedicated CAS at the site so we built the new server with HUB, UM, and MBX only. Before we gracefully remove the original server, i need to figure out an anomoly with the IIS virtual directories. Here's what i'm seeing for IIS virtual directories across the three server: (*The "owa-pda" directory can be disregard.) As you can see, there's a lot fewer virtual directories on the new server. It looks like some of them are redundant between the old sever and the dedicated CAS, so those don't concern me. ..But shouldn't i be seeing some kind of Unified Messaging entry in the server since it has the UM roll installed? I already moved the prompt publishing point to the new server. Is there something else i'm missing? When i run "get-umvirtualdirectory" on the new server it returns no information (no error either.) Thanks in advance!

Duplicate. See this link

Yes, the UM virtual directory is created in CAS role server. See http://technet.microsoft.com/en-us/library/aa996028(EXCHG.80).aspxFiona Liao TechNet Community Support

So, i just tried 'play on phone' using an account homed on the new server. It generates a certificate error (it's the self signed cert from the *old* server.) I'm thinking something needs to be done on the new server to get this working.. Thoughts?

Two part solution, although i'm at a loss to explain it. 1. On the dedicated CAS server i had to add the external url address via set-umvirtualdirectory. Essentially i just duplicated what was already in the internal url field (i.e.http://HostName.CompanyName.com/UnifiedMessaging/Service.asmx) The field was previously empty. 2. After the above change, users no longer got the certificate error, however they started getting a different error about the Exchange server not being reachable. The fix for that one was to change the Outlook Anywhere connection settings on the client so that "On fast networks, connect using HTTP first..." was checked. If neither were checked, or if only "On slow networks..." was checked, the client would get the 'not reachable' error. Weird, but now resolved. :)