Imagine the scenario -- all is working well with your Office 365 hybrid solution until you come into the office tomorrow morning and you get calls saying on-premises users are unable to see the free/busy information for mailboxes in Office 365.  While this sounds like a bad dream, this reality could come true tomorrow morning, so let’s to check to make sure that this does not happen!

The background here is that there is a planned change to the Microsoft Federation Gateway (MFG).  A certificate is being updated which means customers with a federation trust to the MFG must refresh their configuration so that they are aware of the new certificate.  While this will affect Exchange hybrid deployments, it will also affect on-premises deployments that have a trust to the MFG. 

Exchange 2013 SP1 systems installed onto Windows Server 2012 will automatically update themselves, but previous versions of Exchange will not.  The same is true for Exchange 2013 installed onto Windows Server 2008 R2.  Either you do this manually or create a scheduled task to periodically do this work for you.  The steps to create the scheduled task are in the link to the planned change. 

Update 31-10-2014: Added nuance above to call out that manual work will be needed when Exchange 2013 is installed onto Server 2008 R2.

Updating FederationTrust Metadata

The steps to update the MFG metadata are straight forward.  Open the Exchange Management Shell and run:

Get-Federationtrust | Set-FederationTrust –RefreshMetadata

In the example below,  the optional –Verbose option was added:

Testing Federation Trust

We can use the Test-FederationTrust cmdlet to validate the Federation Trust to the MFG.

This is before updating the metadata:

After Get-Federationtrust | Set-FederationTrust –RefreshMetadata  was executed this is the result:

Test CAS User Required To Run Test-FederationTrust Cmdlet

If you have not created the test CAS account to run some of the other test cmdlets or for SCOM, then you will receive the below error:

Couldn't find object "extest_blahblahblahblah". Please make sure that it was spelled correctly or specify a different object

This is a test lab with a single mailbox server so I ran the below to create a single test CAS mailbox. 

Get-MailboxServer | .\New-TestCasConnectivityUser.ps1

Note that in Exchange 2010 there is only one extest account per AD site. 

Viewing Certificate Details in Federation Trust

Use the Test-FederationTrustCertificate cmdlet to see the certificates:

Additionally we can also look at the Get-FederationTrust cmdlet to  see the certificates.  The below screenshots show the certificates before and after updating the Federation Trust. 

Note that in the screenshot below from prior to updating the metadata, the TokenIssuerPrevCertificate  Expires on the 15th of July 2015.

After updating the metadata, the certificates have been changed so that the above TokenIssuerPrevCertificate   certificate has ben replaced:

Go forth and update your metadata, if you have not done so already!

Cheers,

Rhoderick

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

Please be aware of an emerging issue in Exchange 2013 and Exchange Online.  In a delegate scenario it is possible that OWA can be used to delete a folder from the other user’s mailbox and not appear in the Deleted Items section of the recoverable items folder. 

This is covered in KB 2996477  -- Folder deletions are not preserved for mailboxes put on litigation or in-place hold in Exchange Server 2013 OWA.

Update 15-9-2014:  Bharat tweeted that the Office 365 fix is being rolled out and CU7 is the target delivery mechanism for on-premises customers. 

Consider the following scenario:

• You are using Microsoft Exchange Server 2013 or Microsoft Office 365.
• In this scenario, you have two users, User A and User B.
• User A’s mailbox is put on a litigation hold or in-place hold.
• User B’s mailbox is not put on a litigation hold or in-place hold.
• User A designates User B as a delegate to User A's mailbox.
• User B uses Outlook Web App (OWA) to access User A’s mailbox, and deletes a folder from User A’s mailbox or moves the folder to User B’s mailbox.

In this scenario, the deleted or moved folder items do not appear in the "Deleted Items" section of the Recoverable Items folder.

Please monitor the KB for updates and progress on this issue.

Cheers,

Rhoderick

In Exchange 2010 the Set-AdServerSettings  cmdlet is used to manage the AD environment in the current Exchange Management Shell (EMS) session.  In Exchange 2007 there was a variable called AdminSessionADSettings  for the same purpose.  Exchange admins normally use the Set-AdServerSettings cmdlet to change a session’s view scope, so that they can see objects in multiple domains.  By default EMS places the focus on the local domain. 

This can become tedious if we have to change scope at the start of every EMS session. 

This was exactly the question posed during a recent workshop - How to set EMS so that it will default to the forest?

Please note: If any issues are caused by changes in the method outlined below, Microsoft support may request that the changes are removed since they are not officially tested or documented by the Exchange Product Group. You are also advised to document the initial settings so any change can be successfully reverted. 

While we are on the support topic, directly loading the Exchange 2010 and 2013 PowerShell snap-in is not supported except in very specific scenarios.  Those scenarios are documented in release notes and certain KB articles.  The snap-in should not be loaded directly, and a regular remote PowerShell must be used for all normal activities. 

PowerShell Profile Pandemonium

PowerShell does have the option to embed commands into the profile so that they are executed when PowerShell is started.  However if you try to add the Exchange 2010 Set-ADServerSettings cmdlet into the PowerShell profile you will receive an error stating that the cmdlet cannot be found.  This is since the remote PowerShell session has not been establish to make the Set-ADServerSetting cmdlet available.  Bit of a chicken and egg situation…

For completeness sake, this is what some folks will try to do and modify the PowerShell profile.  Please see here for more details on PowerShell profiles you can ask PowerShell by running:

Get-Help about_profiles | MORE

If we check the PowerShell $Profile variable, it shows the following location:

$Profile.PSExtended | Format-List

Let’s modify the PowerShell profile that is referenced in the $Profile variable.  This is the one under the user’s documents folder and is the CurrentUserCurrentHost one listed above. 

Since the folder path does not fully exist, let’s create it and the file with the New-Item cmdlet specifying that it is of type “file”. 

Then Notepad will open up the file so that we can add the Set-ADServerSettings command.

Finally we test expecting great results, but what do we see…..

Bah!  Time for plan ‘B’…. 

Before we move onto plan ‘B’ the above PowerShell profile file should be removed since it does not work.

Plan B

If you view the properties of the Exchange Management Shell shortcut, there are some interesting properties contained within. 

You should see something like so:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

What does the above do?  PowerShell is started specifying the version and that it should not exit after completing the command.  The command to execute is the RemoteExchange.ps1 script that lives in the \Bin Exchange directory.  Then there is the continuation character “;” so execution continues and calls one of the functions created by the Exchange scripts “Connect-ExchangeServer”.  As a side note it is these scripts that customise the EMS and provide the Get-ExBlog, Get-Tip and Connect-ExchangeServer functions.  

Do not modify the Exchange scripts that are signed.  What we can do is shim in an extra command into this shortcut.  Note that the syntax is a little demanding and that the script must be preceded with a “.” prior to the script name.

Let’s Make an additional Script called StartMeUp.ps1 and place this into the C:\Scripts folder.  This is where the Contoso admins place all of their scripts.  Don’t you?  We will then call StartMeUp.ps1 when the EMS is started.  The properties of the EMS are adjusted like so:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer –auto; . ‘C:\Scripts\StartMeUp.ps1’ "

Please note this is one line, though it may wrap. 

The contents of the StartMeUp.ps1 file are shown here for reference:

Set-AdServerSettings -ViewEntireForest $True

Write-Host
Write-Host

Write-Host "Hello Michael, this is KITT.  How are you doing today?" -ForeGroundColor magenta

Write-Host "Your current ADServerSettings are:"  -ForeGroundColor magenta

Get-AdserverSettings

Write-Host

When you then open up the Management Shell, now we automatically have the ViewEntireForest Set to $True without having to do anything!

* - Can you guess what was one of my favourite television programmes from the past?

One thing to note.  If additional copies were made from the initial EMS shortcut (like a desktop shortcut or pinned to the taskbar) they will likely not have the additional script embedded within them.  You may have to delete and then re-pin to the taskbar.

Hope this saves you one line of unnecessary typing every day!

Cheers,

Rhoderick

* – Bonus points if you can remember the name of the bad prototype of this car!   Hint!

In the previous post on the topic of the Registry Editor’s favourites menu, Andrew Higginbotham was kind enough to point out that there was also an easy way to export the favourites from one machine and import to another.  Since its always good to show how to arrive at a solution, let’s breakdown the process of finding out where this data is squirreled.

As always we can use the venerable Sysinternals Process Monitor to tell us where the Registry Editor is saving the Favourites data. 

Brother, Where Art Thou?

To ensure that we do not capture a load of useless data, we can set a filter in Process Monitor to only show us what regedit.exe is doing.  Click on the filter icon, or use the shortcut of Ctrl + L. 

In the process Monitor Filter Window add a new filter for process name is regedit.exe

Click Add, and the regedit.exe process is added

Clear any existing data with Ctrl + X and then make sure the capture is running when we add a test favourite. 

We should then see that the favourites are stored under

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit\Favorites

This is shown below in the capture: 

On that line in Process Monitor,right click the entry and choose “Jump to” or use Ctrl + J to scoot directly to the registry location where the data is stored. 

We can also use another neat shortcut to copy the registry path to avoid typos!  Right click the key, and select Copy key name:

We can export the registry data from here to a .reg file, take that to another server and import it, but let’s automate this! 

Automated Export

Let’s use reg.exe to pull out the data:

REG.exe EXPORTHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit\Favo
rites \\Consea-mb1\stuff\Favourites.reg

Please note that the above command may wrap and is one line.  You will also note that it is saving the .reg file onto a UNC where we can write to.  This can be your home folder or a share where multiple admins have access and you can all access the same shared favourites from  to streamline your operational tasks.  

Automated Import

To then load up our export file run

REG.exe IMPORT \\consea-mb1\stuff\favourites.reg

If you are super keen on the feature, go crazy and add it to your server build process

Cheers,

Rhoderick