Some folks in the field may have seen this before, but it’s worth bubbling up to make sure everyone is aware of it!
I was sitting with one of my esteemed consulting colleagues today and he remarked that it was talking a long time to run one of his Exchange PowerShell scripts. The customer in question is a global organisation with hundreds of Exchange servers in all corners of the globe. My colleague was ensuring that the customer had correctly implemented the design and in essence was auditing the configuration. The script was taking several hours to run.
This customer actually has very good WAN links across the globe and the lines are dedicated for their usage, else the script could have taken even longer!
Whilst discussing this over coffee, and how to wear a shirt correctly (don’t ask), I asked how he was accessing the Virtual Directory information. He was using the default mechanism, which unfortunately is the slowest. So when pulling in the data from each server’s virtual directory it was taking a long, long time. You will see these symptoms with any of the following cmdlets:
- Get-WebServicesVirtualDirectory
- Get-OwaVirtualDirectory
- Get-ActiveSyncVirtualDirectory
- Get-AutodiscoverVirtualDirectory
- Get-EcpVirtualDirectory
- Get-PowerShellVirtualDirectory
- Get-OABvirtualDirectory
For the purposes of this article, we shall use the Get-OwaVirtualDirectory cmdlet, but the behaviour is mirrored for all of the above. The core parameters are the same for all of these cmdlets. Here is the Exchange 2013 link for Get-ActiveSyncVirtualDirectory for example.
What Causes This
When Get-OwaVirtualDirectory cmdlet is executed against a server the default mechanism is to go over the wire and make RPC calls to the IIS Metabase on that sever. This is fine if the server making the request and the target are in the same datacentre. It is not so fine if they are on different continents!
How To Workaround This
The solution to this is frustratingly simple. We can add a parameter to the cmdlet which instructs it not to go to the remote server to get the answer, rather it will query AD to get the data. Since this data is stored within the Configuration naming context in AD, and those Global Catalog servers are conveniently spread across the enterprise we can make a query to a local GC obviating the need to make a remote query.
As an example, you may be running this:
Get-OwaVirtualDirectory -Identity "Contosoowa (default Web site)"
To query AD, simply add –ADPropertiesOnly switch
Get-OwaVirtualDirectory -Identity "Contosoowa (default Web site)" –AdpropertiesOnly
One thing to note the properties stored in the Internet Information Services (IIS) metabase aren't returned when ADPropertiesOnly is used. Only the properties stored in AD are returned. Funny, eh?
Update 12-9-2014: Please also see this post if you are looking for authentication attributes as you may be misled by the results.
Real World Example
Sitting at a machine in Canada running Get-OwaVirtualDirectory against a Singapore machine took just over 5 minutes to return data. With the AdpropertiesOnly parameter I could see the internal and external URLs in less than 2 seconds! WIN !!
Bonus Tip
I personally hate having to specify the "Contosoowa (default Web site)" text when running such cmdlets as it takes more time and is error prone. To avoid this I just specify the server using the –Server parameter. For the vast majority of installations a server has a single OWA VDir so this works well. Should an Exchange 2007/2010 server have multiple OWA VDirs then you may have to be more specific.
Get-OwaVirtualDirectory –Server Contoso-CAS01 –AdpropertiesOnly
One final thing! Don’t go looking for ADPropertiesOnly in an Exchange 2007 Management Shell. It is not there. The below is from an x64 Exchange 2007 SP3 RU10 machine.
Cheers,
Rhoderick
