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*

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.

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:

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.

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. 

Cheers,

Rhoderick