Exchange Virtual Directory HTML Report

Update 12/09/2016: script updated to version 1.8:

  • Included support for Exchange 2016 CU2+
  • Made some minor changes to the code + output now shows a message if successful/unable to write the html file.

Previous updates in version 1.7:

  • Added more recent Exchange build numbers
  • Updated download location to TechNet Script Gallery

You can download v1.8 here

Hi,

as a consultant, I regularly come across situations in which I have to troubleshoot an existing Exchange server environment or perhaps have to make an assessment, health report, etc.

Almost every time, I found myself looking up the information from the different (commonly used) virtual directories like: Autodiscover, ActiveSync, OWA, ECP, Web Services, OAB… That’s why I thought it became about time I automated this process so that I didn’t have to type the commands in manually anymore.

The result is a simple script which will query the Exchange Client Access Servers in your environment and will query them for their virtual directory information. Depending on the use of the virtual directory, different object are shown:

image

Blog Exchange PowerShell

Speaking at IT/DEV Connections & UK UC Day

It’s been a while since I last wrote an article… Although there’s no excuses, I have been pretty busy lately…

First of all, I’ve been ‘heads down’ preparing version 2 of the “Office 365 for Exchange Professionals” ebook.
As Microsoft recently announced, there have been a LOT of updates and those need to be reflected in the book too!
New items include information on the new hybrid configuration wizard, modern authentication, Azure AD Connect and so much more… As Tony mentioned on his blog, we plan on releasing “v2” at IT/DEV Connections in September. If you are attending IT/DEV Connection,  Tony, Paul and I will be there too. Make sure to come and talk to us. We’d love to hear your feedback on the book.

This brings me to the conference itself. This year, I am lucky enough to be speaking there again. IT/DEV Connections is without a doubt one of my favorite tech conferences. It runs at a smaller scale than e.g. Ignite, but there’s a TON of great sessions, all led by even greater speakers! The fact that you aren’t overrun by ten thousands of other attendees allows you to interact with all the speakers. If not during the sessions, there are plenty of opportunities at the evening events or in hallway! You still have time to register, so if you are looking to attend a conference this ‘season’, IT/DEV Connections is what I would recommend. As usual, the conference is held in Las Vegas from September 14 – 17, in the beautiful Aria hotel.

I have two sessions this year. One about Identity Management and Authentication in the online Microsoft world. Although I still have a lot of work to do for my sessions (making sure I provide you with the latest information!), I can share with you that I will also be talking about Windows Hello and Microsoft Passport. This session is on Thursday at 8:30 AM.

The second session is somewhat different from what you’ve usually see me present about. On Wednesday at 11AM, I will be speaking about automation. The idea is not to be giving a theoretical session about how e.g. PowerShell DSC is supposed to work or what PowerShell is; other people are probably better suited for that! It won’t be a level 400 coding session either. I’m no developer and I’m also not a PowerShell guru! It’s rather a hands-on, real-world approach about how you can use all sorts of tools (mainly PowerShell though, but also e.g. Orchestrator) to automate simple and more complex tasks. The idea for this session grew from visiting customers all over the world and seeing how they automated service tasks, onboarding etc… By the end of the session you should have picked up some ideas about what can be useful to you and how to best approach and build it!

Later in September, I will be joining another fantastic line-up of speakers at the UK UC Day in Birmingham. This is the first time this one-day conference is held, but the organisation did not spare any efforts. A lot of speakers from IT/DEV Connections will be there and it’s good to see some speakers join us from the US too! This time, I will be speaking about hybrid deployments in all its glory. Single-forest, Multi-Forest, AAD Connect and many other things will be discussed. A high-paced session, but definitely for you if you are in a hybrid deployment, you are looking to configure a hybrid connection or you’re a consultant that deals a lot with hybrid!

ENow will be represented at both conferences as well! In the UK we are joined by the team of Essentials. Make sure to stop at our booth and have a conversation! We look forward to another great conference and an even greater Scheduled Maintenance party!

Looking forward to seeing you there!

-Michael

 

 

Blog Events

[updated: July 20, 2015] Script: putting Exchange Server 2013 into Maintenance Mode

Latest Update:

v1.8 (07/20/2015): fixed a copy/paste error in the script and cleaned up the code to be a little more efficient (removed redundant IF-statement. Published the script to the TechNet Script Gallery for easier download access.

Introduction

In Exchange 2010 one had the option to put a Mailbox server which was part of a DAG into “maintenance mode” by running the “StartDagServerMaintenance.ps1” script that was included with the product. Likewise StopDagServerMaintenance.ps1 was used to pull a server out of this so-called maintenance state. In fact, this script would move any active mailbox databases to another node in the DAG and mark this server as temporarily unavailable to the other servers. That way, if a failover would occur during the server was in ‘maintenance mode’ you wouldn’t risk that it ended up as a valid failover target.

Exchange 2013 now has the ability to go beyond what was possible before and extend this functionality. You now have the possibility to put an entire server into maintenance mode, meaning that also components like e.g. Transport Service or the Unified Messaging Call Router are temporarily put on hold why you do some work on your server.

There might be various reasons to put a server into maintenance mode. For instance when you need to install software or you want to do some troubleshooting without affecting users that might have a mailbox in an active mailbox database on that server. To facilitate the process, I created two scripts which will automatically put an Exchange 2013 Server in or take it back out of Maintenance Mode.

The manual process

The process for putting an Exchange 2013 server into maintenance mode is relatively straightforward. To enable the Maintenance Mode, you must run the commands below.

If the server is a Mailbox server and before you can disable the transport service, all active queues need to be drained first. To help clearing out the queues, existing messages on the server will be moved to another server. Please note that the TargetServer value has to be a FQDN:

Set-ServerComponentState  -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server  -Target <server_fqdn>

If the server is part of a DAG, you must also run these commands:

Suspend-ClusterNode
Set-MailboxServer  -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer  -DatabaseCopyAutoActivationPolicy Blocked

Once all queues are empty, you can disable all components:

Set-ServerComponentState  -Component ServerWideOffline -State Inactive -Requester Maintenance

Taking the server out of Maintenance Mode is a matter of simply reversing the actions we took to put it into Maintenance Mode.

First, we reactive all components:

Set-ServerComponentState  -Component ServerWideOffline -State Active -Requester Maintenance

If the server is part of a DAG, you need to reactive it in the cluster (by resuming the cluster node):

Resume-ClusterNode
Set-MailboxServer  -DatabaseCopyActivationDisabledAndMoveNow $false
Set-MailboxServer  -DatabaseCopyAutoActivationPolicy Unrestricted

If the server is a Mailbox Server, the transport queues need to be resumed as well:

Set-ServerComponentState –Identity  -Component HubTransport -State Active -Requester Maintenance

Although not explicitly required, it’s best to restart the transport services after changing their component states. This ensures they ‘pick up’ the changed component states immediately rather than having to wait for Managed Availability (Health Service) to take action.

Using the scripts

Sometimes it can take a while before active queues are drained. Because I do not always want to wait in front of the screen and periodically check the queues myself, I created two little script that fully automate the process explained above. Besides the required steps, the scripts also perform additional safety-checks and inform you about other server component states which might prevent a server from working correctly.

The first script, Start-ExchangeServerMaintenanceMode.ps1 will put a server into Maintenance Mode, whereas Stop-ExchangeServerMaintenanceMode.ps1 can be used to take a server out of the maintenance state.

Please note that the scripts rely on built-in Exchange functions and therefore need to be run from the Exchange Management Shell.

Version history

v1.8 (07/20/2015): fixed copy/paste bug; removed duplicate code and made some overall improvements to script efficiency.

v1.7 (07/08/2015): removed the requirement to dot-source the script. Published the script to the TechNet Script Gallery for easier download access.

v1.6 (29/11/2013): some minor bug fixes in the Start-ExchangeMaintenanceMode script.

v1.5 (28/11/2013): Based on feedback from several readers, I’ve improved the scripts by rewriting parts of the code and, as such, making it more lenient and more usable in scenarios where you want to run the script from a remote Exchange server. The script now also restarts the Transport service(s) after changing their component states. This ensures that the new component states are picked up immediately, rather than after Managed Availability kicks in. Without the change it could take anywhere from a few minutes to a few hours before the transport services were really inactive/active again. The download links at the bottom of the page are updated to point to the new versions of the scripts. Last, but not least, when ending a maintenance mode, the script will query the server for any components that might still be inactive and display a warning if any are found. A special thanks to Dave Stork for some of the ideas!

v1.4: update the script to include some additional error checks. First it will check whether the person who is executing the script has local admin rights. If not, the script will throw a warning and exit. Secondly it will also check whether the TargetServer name can be resolved. If it’s not an FQDN, it will resolve it to an FQDN. If it cannot be resolved, an error will be thrown.

v1.3: after some feedback from Brian Reid (thanks Brian!), I’ve finally updated the script to include the “Redirect-Message” cmdlet. This will ensure that the queues will drain more quickly on the server by moving messages from one server to another. Have a look at Brian’s blog if you need more info: http://blog.c7solutions.com/2012/10/placing-exchange-2013-into-maintenance.html

v1.2: Maarten Piederiet emailed me pointing out that he had encountered some issues while using the script. Apparently, while draining the message queues, the script ran forever because it waits for every queue to become empty; including Poison- & Shadow Redundancy queues. To avoid this from happening, he made a minor change to the script to now excluded both queues. Thanks for the tip!

The scripts

Below you find links to my SkyDrive from where you can download the scripts. Enjoy!

Start-ExchangeServerMaintenanceMode (v1.8)

Stop-ExchangeServerMaintenanceMode (v1.5)

Disclaimer: these scripts are provided “as-is” and are to be used on your own responsibility. I do not and cannot take any reliability for the use of these scripts in your environment. Please use with caution and always test them before use.

If you have suggestions, comments or think things can be better: please let me know! Your feedback is greatly appreciated!

Blog Exchange PowerShell

Azure AD Synchronization HTML Report

In 2013, Exchange Server MVP Mike Crowley wrote a script which would interactively report on the Office 365 Directory Synchronization tool. In 2014, Mike and I worked to update the script so that an HTML report would be generated. This would allow you to schedule the script and have the output emailed to you without the need to run the script interactively.

Before you can actually run the script, you will have to install SQL PowerShell on the AADSync machine first. DirSync had this installed by default, but it seems that AADSync does not. To install the SQL PS module, you must install the following components separately:

  1. Microsoft® System CLR Types for Microsoft® SQL Server® 2012
  2. Microsoft® SQL Server® 2012 Shared Management Objects
  3. *Microsoft® Windows PowerShell Extensions for Microsoft® SQL Server® 2012

The binaries can be installed from the installation instructions on the following page: http://www.microsoft.com/en-us/download/details.aspx?id=29065

Once you have installed the components, run the following command from the AADSync server and verify that the SQLPS module is listed:

Get-Module -ListAvailable

Once you have verified the SQLPS module is installed and available, you can run the script.

This time around I have decided to publish the script through Github. You can download it from HERE. Alternatively, the script also available from the Technet Script Gallery, HERE.

Please use the script for what it’s worth, and always test in a lab first. Comments/feedback and feature requests are always welcome!

Blog Office 365 PowerShell

Exploring Exchange Server Component States

As described in a previous article, an Exchange 2013 server can be placed into a sort of maintenance mode, not only by temporarily pausing a DAG node from the cluster, but also by putting Exchange components on that server into an inactive state using the Set-ServerComponentState cmdlet.

The most obvious reason why a component is in an inactive state is because someone put it into that state as part of a maintenance task. However, there can be several other reasons why a component is inactive. The most common reason is when the Health Management service (part of Managed Availability) has taken a component offline because it was deemed unhealthy.

The tricky part comes when one or more “requesters” have put a component into an Inactive state which might lead to confusing situations. There are 5 requesters that can switch the state of a component:

  • HealthAPI
  • Maintenance
  • Sidelined
  • Functional
  • Deployment

Consider the following scenario. As part of the upgrade to the latest CU, you decide to put a server into maintenance mode using the Set-ServerComponentState cmdlet. After the upgrade, you take the server back “online” by changing the state of the component back to “Active”. However, when running the Get-ServerComponentState cmdlet, you notice that one or more components are still inactive… You investigate the issue and it turned out that the component was already in an inactive state before YOU put it in an inactive state. So why didn’t the state change AFTER you put it into an active state again?

The answer is pretty simple. As you know, only the requester that has put a component into a certain state, can put it back into an active state. So, as part of your maintenance task, you’ve put a component into maintenance using “Maintenance” as the requester, you are actually flagging the service inactive for a second time.

In fact, every time someone (or something) makes a component inactive, an entry gets added to the local server’s registry in the following location:

HKLM\SOFTWARE\Microsoft\Exchange Server\v15\ServerComponentStates\<componentname>

image
this image displays the different entries for the FrontEndTransport component in the local Exchange server’s registry

Each entry includes the following information, separate by a colon: [Unknown Value]:[State]:[TimeStamp]
By looking at the picture, you can see that the requester “Maintenance” has put this component into an active state on the given timestamp. FYI, the timestamp is saved in a binary format.

Now consider the following image:

image

As you can see, the component has multiple entries. Luckily, all of them are showing that the component is Active. However, if one of the entries would show the component was inactive, it would effectively be inactive. Even if a more recent entry would place that component into an active state, it would remain inactive until the same requester switches it back to active.

Why is that, you might wonder. Simply because there are cases where you don’t want someone to override the component state set by someone or something else. This could be the case when someone placed a server into maintenance mode (requester = Maintenance) and while the server is in maintenance, someone updates the Exchange server to the latest version. Exchange setup will actually place all components into an inactive state prior to starting the upgrade (requester  = Deployment) and switch them back after the upgrade completes. If this action would override the component state set by “Maintenance”, the server would effectively become operational again. Something you might not want in this case.

Script to query Component States

The output of the Get-ServerComponentState cmdlet does not show who placed a component into an inactive state, nor shows it if there’s more than one entry for that component. Of course, you could each time have a look in the local server’s registry. For convenience reasons, I put together a little script that will query the local registry and output the information on-screen:

image

Below you’ll find the code for the script. All you need to do is save it as a .ps1 file and run it from the Exchange Server that you want to query. Alternatively, you can download the script from here.

The current version of the script is a bit rough, but it works 🙂
In a future version, I’ll try to add remoting and clean up the code a bit by adding comments…

$components = Get-ChildItem HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates\ -Recurse | select PSPath

foreach($component in $components){

$componentstates = (Get-ItemProperty $component.PSPath | Select * -ExcludeProperty PS* ) | Get-Member -MemberType NoteProperty

$i=0

do {

$componentstate = ($componentstates[$i].Definition).split("=")
$statebreakdown = $componentstate[1].Split(":")

#$componentActualState = $statebreakdown[1]

switch($statebreakdown[1]){
1 {$componentActualState = "Active"}
0 {$componentActualState = "Inactive"}
}
$componentActualTime = [timezone]::CurrentTimeZone.ToLocalTime([datetime]::FromBinary($statebreakdown[2]))

$obj = New-Object PSObject
$obj | Add-Member -MemberType NoteProperty -Name Component -Value $($component.PSPath.Split("\"))[7]
$obj | Add-Member -MemberType NoteProperty -Name Requester -Value $componentstates[$i].Name
$obj | Add-Member -MemberType NoteProperty -Name State -Value $componentActualState
$obj | Add-Member -MemberType NoteProperty -Name TimeStamp -Value $componentActualTime
$obj

$i++
}
while ($i -lt $componentstates.count)

}

What’s next?

In a follow-up article, I’ll discuss the Server Component States and why the entries also exist in Active Directory.

Exchange 2013 How-To's

Updating the FriendlyName property of a certificate using PowerShell

Update: you actually *can* update the property (even if it’s not there). Seems I was just too blind to notice it earlier. Thanks to Michel De Rooij for pointing this out.

In one of my earlier articles, I wrote about how to integrate Office Web Apps with Exchange Server 2013. As part of that process you had to configure the Office Web Apps farm with the name of the certificate that the farm would use.

The certificate attribute that you have to use is stored in the “Friendly Name”-property of the certificate. Although it’s pretty easy using the MMC (duh!), it’s always nice being able to do something through PowerShell.

According to an article I found, certutil.exe could be used to add a Friendly Name to a certificate. Although CertUtil.exe certainly proved its value in the past, I’m not particularly fond of it either.

Unsurprisingly, the solutions with PowerShell is pretty easy! Using the Set-Location cmdlet, you can change your active namespace to the certificate store:

Set-Location cert:

From there, navigate to the location where the certificate you want to add (or change) the property for. For instance:

cd .\\LocalMachine\My

Using Get-ChildItem we can retrieve a list of all the certificates in the store:

Get-ChildItem
PS Cert:\CurrentUser\my> Get-ChildItem

Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\my

Thumbprint Subject
---------- -------
FEA21BCDB0FBFC2B00EBE4DA8A524D0C0999FBDC E=michael@vanhorenbeeck.be, CN=michael@vanhorenbeeck.be, Description=fgt8C...
100953EB6F74F5B60937BB0C7329037D9AE9927A CN=xowas.xylos.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com
070D4C36B95D9550488F4A2DDCEAF76F5B6C7AAA CN=outlook.linkedinlabs.com, O=DO_NOT_TRUST, OU=Created by http://www.fidd...
0224B3E25491F1A7F71D8367B147F41F3C1250D5 CN=www.google.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com

Once you’ve determined what certificate you want to update, we need to query the certificate and update the FriendlyName property as follows:

$cert = GCI
$cert.FriendlyName = “FriendlyName”
PS Cert:\CurrentUser\my> $cert = gci 070D4C36B95D9550488F4A2DDCEAF76F5B6C7AAA
PS Cert:\CurrentUser\my> $cert.FriendlyName = "FriendlyName"

That’s it! To verify that the property was set successfully, do the following:

gci
 | fl name,FriendlyName
PS Cert:\CurrentUser\my> gci 070D4C36B95D9550488F4A2DDCEAF76F5B6C7AAA | fl ThumbPrint,FriendlyName

Thumbprint   : 070D4C36B95D9550488F4A2DDCEAF76F5B6C7AAA
FriendlyName : FriendlyName

Exchange 2013 PowerShell

How to check what the version of your tenant is in the cloud (Office 365)

I sometimes get the question how one can verify what the version of Exchange they’re running in the cloud. Although it should be pretty obvious based on the GUI (Exchange 2010 vs. Exchange 2013) and the fact that the latter isn’t generally available yet, it could come in handy once it does. According to some sources, the release might be sooner than later.

Additionally, when you’re planning on going hybrid with the new version of Exchange in Office 365, you’ll have to make sure your tenant isn’t in the process of being upgraded and is running version 15.

To check the version, open up a PowerShell session to your Office 365 tenant and run the following command:

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization

With the command for connecting to Office 365 via PowerShell, that would look something like this:

$session = New-PSSession –ConnectionUri https://ps.outlook.com/powershell –AllowRedirection –Authentication Basic –Credential (Get-Credential) –ConfigurationName Microsoft.Exchange

Import-PSSession $session

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization

Running these commands would then lead up to a result similar to the following:

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization -Autosize

AdminDisplayVersion IsUpgradingOrganization
------------------- -----------------------
0.10 (14.16.190.8)                    False
How-To's Office 365