Using ADPropertiesOnly With Exchange Virtual Directory Cmdlet Shows False Positives

Previously we discussed an interesting feature of the Exchange virtual directory cmdlets where they check data stored in AD, rather than making a trip to the server and querying its IIS metabase.  For the details on this, please read the original post here: Slow Response To Exchange Virtual Directory Cmdlets.

In that article we were using the ADPropertiesOnly switch so that it was very quick to review all of the URL settings on hundreds of Exchange servers.  This worked very well, and saved many hours of waiting for remote servers to respond.

Then one of my colleagues noticed an issue checking the auth types on the virtual directory, which was initially interpreted as a false positive by the customer.

In the below example we are running two commands.  The first one is what most folks normally use and then in the second example the ADPropertiesOnly switch is added.

Get-OWAVirtualDirectory –Server Consea-HT-Cas1 | Select Name, *auth*

Get-OWAVirtualDirectory –Server Consea-HT-Cas1 –ADPropertiesOnly  | Select Name, *auth*

Get-OWAVirtualDirectory - Checking Authentication Types Set In Metabase

Looking at the output closely we can see that there are differences in the output.   For example, look at the BasicAuthentication field.  This is highlighted below to show the difference.

Highlighted Basic Authentication Line

When looking at the ADPropertiesOnly line, BasicAuthentication is reported as $False.

Checking in the IIS console locally on the server, we can see that Basic Auth is present and enabled:

Basic Authentication Enabled In IIS Console

The properties in the Exchange 2010 Management console are shown below for this OWA virtual directory.  Note that it shows the default permissions for an Exchange 2010 SP3 box.  Forms based auth is selected, and the tick boxes for integrated windows and basic auth are implicitly enabled.

Current Authentication Settings In Exchange 2010 Management Console

What’s up?  Why is ADPropertiesOnly showing $False  for basic auth when basic is enabled?


Caveat Emptor

Looking at Exchange 2013’s Get-ActiveSyncVirtualDirectory cmdlet, we see the following description for ADPropertiesOnly:

ADPropertiesOnly switch specifies whether to return only the properties about the virtual directory stored in Active Directory. The properties stored in the Internet Information Services (IIS) metabase aren't returned

The OWA virtual directory object is stored in the below location in AD’s configuration naming context:

Dn: CN=owa (Default Web Site),CN=HTTP,CN=Protocols,CN=CONSEA-HT-CAS1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com

The auth properties are listed below for reference, but do not manipulate them directly:

msExchExternalAuthenticationMethods: 4;
msExchInternalAuthenticationMethods: 23;

So we can see that Exchange is able to query against the values stored in AD.  This is returned in the msExchInternalAuthenticationMethods cmdlet out.  However the additional metabase properties are not returned.

The way this is shown in the cmdlet output using ADPropertiesOnly is with a $False.  Maybe $Null could have been used.

Either way, the net result is that ADPropertiesOnly works great for those properties that do not require a trip to the metabase and be careful to ensure that you don’t read too much into a false positive result.  Use the attributes that are stored in AD for such comparisons – the ExternalAuthenticationMethods and InternalAuthenticationMethods




Comments (9)

  1. anonymouscommenter says:

    Some folks in the field may have seen this before, but it’s worth bubbling up to make sure everyone

  2. anonymouscommenter says:


  3. anonymouscommenter says:

    Hey Roderick,

    I actually ran into this issue today, great blog post!

  4. Recep YUKSEL says:

    Thank you Mr. Roderick.

  5. anonymouscommenter says:

    So what’s the workaround? How do you get information from exchange servers at multiple sites, if you can’t trust the data coming out of ADPropertiesOnly? I don’t have hundreds of servers, I just have four, located on four continents, and I can’t run something
    like get-autodiscovervirtualdirectory without waiting for hours (and since we have an idle auto-logout policy, that means unless I babysit my RDP session, I can’t run these cmdlets at all!)

    What’s the best practice, here?

  6. I’d workout where each server resides, connect to that server specifically using remote PowerShell do what I need to do and rinse repeat.


  7. anonymouscommenter says:

    That’s pretty much what I was afraid of. It works, but it’s inconvenient (and doesn’t scale too well. It works in my environment, but not in your "hundreds of servers" scenario). Is there anything in the pipeline to address this in the future?

  8. Nothing in the pipeline ( pun intended ) that I can share.

    Though it is not that hard to script around. Maybe I can do that when I get some time.


Skip to main content