AAD SSO Feature & security

“Once domain admin – always domain admin”

Nice article about the new SSO feature and securing it:



Script to get all Exchange CU/RU via PowerShell from Technet

Today one of my colleagues was trying to create a fully automated Exchange patching script. One of the challenges was to retrieve the latest CU/RU for a specific Exchange version. As every IT Pro now they are nicely listed on the Technet website.

To get the url the download the update package we needed to  scrape the Technet site. For this I wrote a little script which will leverage the HTML Agility Pack.

Can be installed using NuGet:

Install-Package HtmlAgilityPack

If you have added nugget as a repo:

Register-PackageSource -Name nuget.org -Location http://www.nuget.org/api/v2/ -ProviderName nuget

The following code will get all updates from the technet website:

$url = “https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx”

# HAP required http://htmlagilitypack.codeplex.com/

Add-Type -path ‘C:\Program Files\PackageManagement\NuGet\Packages\HtmlAgilityPack.\lib\Net45\htmlagilitypack.dll’

$wc  = New-Object System.Net.WebClient;

$doc = New-Object HtmlAgilityPack.HtmlDocument


$result = $doc.DocumentNode.SelectNodes(‘//table/tr/td/p/a’)

$Updates = $null

$Updates = @()

foreach ($link in $result)


$url = $link.Attributes[“href”].Value

#$name = $link.InnerText

$name = ($link.ParentNode.ParentNode.ParentNode | ? {$_.InnerHtml -like ‘*date*’}).ChildNodes[1].InnerText.TrimStart().TrimEnd()

$build = ($link.ParentNode.ParentNode.ParentNode | ? {$_.InnerHtml -like ‘*date*’}).ChildNodes[5].InnerText.TrimStart().TrimEnd()

$longdate = ($link.ParentNode.ParentNode.ParentNode | ? {$_.InnerHtml -like ‘*date*’}).ChildNodes[3].InnerText.TrimStart().TrimEnd()

$date = Get-Date $longdate -Format ‘dd/MM/yyyy’

$update = New-Object PsObject -Property @{ Name = $Name; URL = $url; Build=$build;Date=$date;} | Select-Object Name, Date, Build, URL

$Updates += $update


$Updates | ft



Have fun!

Cross premise mailbox permissions

During an Office 365 migration at a customer we had some issues with cross premise mailbox permissions (Full Access).

For more information about take a look at: http://www.msexchange.org/articles-tutorials/office-365/exchange-online/exchange-hybrid-cross-premises-mailbox-permissions-demystified-part1.html

After a while we started noticing that some users where able to open shared mailboxes and some users weren’t.

After further investigation we found that when creating new cloud mailbox using the Enable-RemoteMailbox command, the msExchMailboxGuid was not provisioned correctly:

In the cloud we see the correct GUID:


But on premise this GUID was not provisioned correctly:


When looking at the AAD Connect Rules Editor, we couldn’t find any rules to allow syncback for this attribute:


The O365 Support Team confirmed us, that to allow Cross premise mailbox permissions these attributes should be provisioned.

This can be done manually using powershell:

Set-RemoteMailbox <MailboxName> -ExchangeGUID <GUID>

We did found an article that cloud born mailboxes cannot be migrated to on premise because of the fact that this attribute is not provisioned:


Eventually we opened a case with Microsoft Premier to ask why this was not the case. The answer we got was that this is by design and there are no plans to fix this any time soon.

So just be aware that i some cases migrating mailboxes can be preferred over  creating them in the cloud directly.


Exchange 2010 Cross Forest Migration

Nice & compact 🙂


Here is the scenario of my test lab which we will be following.

Source Forest: Exchange 2010
Target Forest: Exchange 2010
AD Functional Level: Both running at 2008R2

You have been given a chance to work on a project for cross forest migration for your company. In this article i will elaborate the step that you need to perform in order to do cross forest migration.


1. Active Directory trust is in place between both the organization
2. Exchange connectors have been setup for email flow internally.

Once you have AD Trust and Exchange connectors in place then the following steps needs to be performed to migrate users and exchange mailboxes from source forest to target forest

1. Install ADMT on target Exchange domain joined machine.
2. Install Password Export Service on source domain controller if you want to migrate users accounts with password.
3. Run ADMT to migrate…

View original post 533 more words

Azure AD Global Admin – No Subscriptions Found


If you’ve assigned a new user in Azure AD as a global admin, but when logging into https://manage.windowsazure.com/ with that new user, you may receive a message “No Subscriptions Found”.


To correct this problem, it’s a matter of adding the user a subscription administrator.  In Azure AD, navigate to Settings > Administrators, then click Add+ at the bottom.


View original post

Logging original source IP in IIS logs for Exchange behind Kemp Load Balancer

One of my clients requested to get the original source in in their IIS logs for auditing. They are using reverse proxies (KEMP) and IIS logs. The problem is that they have a non-transparent architecture and thus the traffic is terminated on the Kemp and the original client IP is lost. This means that the c-ip (client ip) in the logs will always be originating from the Kemp.

Luckily load balancers are able to add the original source address to the HTTP headers. By changing the load balancer’s configuration of each sub virtual service. We were able to add the original IP address to the X-Forward-For HTTP header:


The problem is that IIS still keeps logging the original ip address in the c-ip field in the logs.

For this there are 2 options. We can user advanced logging (IIS 8.5 & later) or use a custom IIS module.The preferred scenario is the first (A). But in some case it might be required to use the c-ip field instead of custom field.

SCENARIO A: Advanced Logging

With advanced logging it’s possible to add a custom field to the IIS logs. In our case we want to add the X-FORWARD-FOR header to the logs. This can be achieved via the IIS manager:


Now we will see the new field in the log files:


NOTE: When using log parser make sure to change the log format to W3CLOG to support custom fields.


An F5 employee developed an IIS module that will change the c-ip to the X-Forward-For address when present.

The source and binaries for this module can be found here: https://devcentral.f5.com/articles/x-forwarded-for-http-module-for-iis7-source-included

To install the module just copy the contents of the x64 Release bin to your Exchange server and run the install script from a PowerShell prompt:


When done you will see that the IIS logs now include the the original client ip:


One happy customer!