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.
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:
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:
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.
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?
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.
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:
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.
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 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.
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-HostWrite-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
Set-AdServerSettings -ViewEntireForest $True
Write-HostWrite-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!
* – 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.
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!
Let’s use reg.exe to pull out the data:
REG.exe EXPORTHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit\Favorites \\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.
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
A virtual machine from Windows Server 2012 R2 cannot be directly imported into Windows Server 2012. This is discussed in this previous post along with the import error 32784 .
There will be times when we want to take a 2012 R2 VM and import it into 2012, this happened to me recently when setting up one of the workshops that I deliver to customers. While the setup guide said to deploy 2012 R2, what was installed was another story as the setup team had not prepared 2012 R2 builds for this environment.
So what to do?
While the 2012 R2 VM configuration file cannot be imported into 2012, the virtual hard disk can be reused!
This post will walk through reusing the original VHD with a new 2012 configuration file. We will assume that the VM in question is a generation 1 VM, since generation 2 VMs were first introduced on 2012 R2! Please note that the intent of this post is to provide workaround steps for lab or test VMs, and is not intended to be taken as a supportability statement.
We will focus on one VM that is called EMSDC and is currently stored in the C:\VMs-EXT folder. This is the location where the VM should reside so there is no need to move files around.
The files on disk are shown below. Note that the directory structure is pretty straightforward and that there are only two files:
The files that you see are the XML configuration file and the VHD virtual hard disk. If you prefer to see the directory in explorer that is also shown:
Since we cannot import the Server 2012 R2XML file, we shall back it up and then delete the original from the Virtual Machines folder.
Note that in the bottom section of the below, the F5164EF0***.XML file has been deleted.
Now that we have removed the original configuration file, we can make a new one.
In this example we will use the Hyper-V manager to create new a VM configuration which will reuse the original VHD.
First up, start the New VM wizard.
Specify the same VM name in the wizard. Note that the location is also entered so that we build the complete configuration in the same set of folders. You could leave the default if you wanted, but I wanted to mimic the original configuration. Note that the location path specified is C:\VMs-Ext and is not C:\VMs-Ext\EMSDC.
Specify the memory and network configuration.
This leads to one point. You need to know what values to enter here, as this wizard has no knowledge of what the original VM was set to. Documentation to the rescue!
The default options are shown below for the connect virtual disk screen. The default is to create a brand new VHDX within the VM folder. This is not what we want as that does not contain our OS and applications from the original VM’s VHD.
Thus we have to change the options so that we will use the existing VHD. This is shown below:
Finally we complete the new VM wizard.
And it is shown in the 2012 Hyper-V manager.
If we review the settings for the VM we can see that the original VHD is attached to the IDE controller.
Referencing the original disk layout, we can see that the starting configuration XML file was removed then a new XML file was created.
At this point we can now power the VM on, though we still have work to do!
At this point it is very likely that the installed version of the Hyper-V Integration Components (IC or ICs) are not what we require. In this case the 2008 R2 ICs are installed which causes the 2012 devices to be improperly recognized. If you open device manger the below will likely be observed.
To check the Integration Component version we can look at the vmbus.sysfile
6.1.7601.17514is one of the Windows 2008 R2 IC builds. In this case we need to upgrade to a 2012 IC version. Depending upon your VM, you may need to uninstall the existing IC and downgrade them.
When updating the ICs I have had better success when the OS has had sufficient time to complete the hardware detection process. Once this process has finished, Windows will then prompt for a restart.
Be sure to wait for the hardware detection to complete. This is indicated with the prompt to restart. Be patient – you may need to wait for various services and applications to time out – and the desktop may go black as this happens.
Once restarted, log on and then align the Integration Components. Again - this example is one where the ICs need to be upgraded.
When the install has completed you will be prompted to restart:
I noted that on some of my VMs if I did not allow the initial hardware detection to complete and immediately tried to upgrade the Hyper-V Integration Components, the machine would get stuck at the Preparing to Configure Windowsscreen. This is why I would wait for the initial hardware detection to complete; and when prompted restart the VM prior to changing the Integration Components.
At this point we have a new VM configuration which uses the original VHD and the Integration Components are at the right build level. The virtual hardware inside the VM should all be recognized
One issue caused by replacing the VM configuration is that Windows sees a new NIC. This means that any static IPs inside the VM must be re-assigned. If this is done successfully Windows will prompt that you are assigned an existing IP to the new NIC and ask if you want to overwrite the configuration.