donderdag 20 oktober 2011

Moving mailboxes from on-prem to Office365, TCP connection issues with TMG / ISA

When we were moving mailboxes from on-prem to the cloud we ran into some trouble.
The first two mailboxes were moved fine, but when we added more move-requests all requests failed.
The most common error we got was "StalledDueToMailboxLock" and "TransientFailure".

Things we tested first were internal moves. Creating a second Exchange Dbase and moving mailboxes to that Dbase. All moves completed succesfully. My conclusion : Not an Exchange issue but a network issue.
That lead us to our TMG server.
We checked the alerts in TMG and the following error draw my attention.

When opening the alert, you will see that the IP address starts with 157.55 ( in almost all cases ).
These are Microsoft IP adresses, and therefore the moves will not complete successfully because TMG cuts off the request.

We resolved the issue by adding an IP exclusion for Flood Mitigation.
This can be found under the configuration tab, and choosing "general"
Then choosing "Configure Flood Mitigation Settings".

We added an IP exclusion for the range of Microsoft Exchange servers. We added the complete 157.55.x.x range.

Click OK and dont forget to save your TMG configuration.
This had a direct effect on my mailbox moves, they worked!

These settings are the same in ISA of TMG, it's possible that the flood mitigation settings are on another tab, but in general the settings are the same.

Hope this helps in your Office 365 migration.

zaterdag 15 oktober 2011

How to delete a user from Office 365 which has been synced with Dirsync

I have been testing some things with my account in Office 365.
Unfortunately, where people are testing, thing go wrong.

Somehow, my user in Office 365 got corrupted and all of my things in the cloud were unavailable.
Luckily , it was a test user and no actual data got lost.

First things first. I want to point out that deleting a user in Office 365 using this method also deletes the corresponding mailbox and all the other settings for other Office 365 products.
Only use this as a last effort to delete the user/mailbox.

So, we need to delete the user from Office 365. Easy, just log in to the portal, browse to the user and click delete.
Because the users got synced with Dirsync, AD is leading and therefore the user can't be deleted from the portal.

Well, then I tried deleting the user with Microsoft Online Module for Powershell. ( Installed on ADFS )
First, connecting to the MSOLService and importing the cmdlets to manage Office 365.
Next step was removing the user with the following command.
"Remove-MSOLuser -userprincipalname "userlogonname"
Again, AD is leading so powershell gave me the following error.

Then I thought, AD is leading, Dirsync is ILM, so there must be another way.
And there is! Using the ILM console we can successfully delete a user from Offie 365, without deleting the user in AD.
It is recommended to do this just after a sync, because we don't want Dirsync to start syncing while we are changing things in ILM.

Open the ILM console on the Dirsync server : C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell\miiclient.exe
Then open the tab " Metaverse Search"
The metaverse is a database that keeps track of user data from all the connected systems.
In this case we only have 2 systems, AD and Office 365.
So in the met averse search we will find one User ( person ) with data from AD and Office 365.

Create a new search scope to find the user you want to delete from Office 365.
Once the user is found, double click the user.

Open the tab "Connectors" .
You will see 2 connectors, one with all the imported data from AD, and one with all the exported data to Office 365.
Select the AD connector ( where Management Agent value is SourceAD) and click "Disconnect" so only the Office 365 connector ( TargetWebService ) remains.
This simulates the user being deleted from AD, as there is no longer any data present for the AD connector.

Next, go to the Management Agents tab.
Right click the "TargetWebService"  connector and choose "Run".
Select the "Full Confirming Import" run profile and click ok.

Repeat the steps above and choose the "Export" run profile instead of the Confirming Import.
When the export is finished, the user object is deleted from Office 365.
This is also shown in the history under the operations tab in ILM.
Click the last task and the deletion will be shown in the bottom left corner.

In the next Sync the user will be recreated in Office 365.

If you want to create a new on-premise mailbox for the user ( because the Online mailbox is deteled, and there is no on-prem mailbox ), there are a couple of extra steps to follow.
If you open the Exchange EMC right away and use the " new-mailbox " command for the just deleted user, you will notice the EMC cannot find your user as it searches for users with no mailbox.

To create a new mailbox for the existing user you have to clear all the exchange attributes in AD for that user. If you open the attribute editor you will notice that all the Exchange attributes remain in AD. If you don't clear the values, Exchange EMC will not create a new mailbox.
Open the properties of a user without a mailbox, and check which attributes had no value.
Clear the ones that don't have a value with the non mailbox enabled user.

Again, only use this as a last effort because all mailbox content is deleted.
If this happens with a normal user instead of a test user, there is a way to get your e-mails back.
With my test user, I opened outlook in Offline mode and created a PST, Cached mode needs to be enabled for this to work!
When the new mailbox was created I imported the PST and the e-mails are back.

Hope you don't have to use this, but it's good to know how a user can be deleted.

vrijdag 14 oktober 2011

Filter unwanted users ( like service accounts ) from Office 365 with Dirsync

If you are using Office 365, you will probably notice that Dirsync syncs all users in AD.
Even the service accounts, and other test accounts that you don't want in Office 365.

There is a solution.
Dirsync is actually ILM ( FIM in 64 bit version ), so it uses Management agents for importing AD and exporting to Office 365.
A good thing, because we can use the ILM interface to create filters.

The thing you have to do is start the ILM tool, not the Dirsync tool.
The ILM tool can be found in : C:\program files\Microsoft Online Directory Sync\SYNCBUS\UIShell\miisclient.exe
If you open that file, the ILM interface will open.

To create filters for AD, we need to open the properties of the SourceAD Management Agent.

Then, click the "Configure Connector Filter" tab and select "user" as the Data Source Object Type.
There are already some filters present for the user object which are configured by default.

To add some filters you click the "new" button. In the example below, I configured a filter that excludes users with an accountname that starts with "svc_", because I don't want my service accounts to be created in Office 365. The possibility's with these filters are almost endless.

If Dirsync hasn't synced before, you do not have to follow the next steps.
When Dirsync starts its first import all the user objects present in AD, it will filter out the accounts that meet the filter's condition.

If the initial sync already took place, you need to follow the steps below.
First, we need to do a "Full Import and Sync" for the SourceAD connector.
You can do this by right clicking the SourceAD management agent and choose "Run".
This will open the configured run profiles and will let you choose one.
Choose "Full Import and Sync" and click OK.
This will take some time, depending on the number of objects in AD.

In the import and sync, the Management Agent notices that there are some objects in AD that have been filtered out, so called "Filtered Connections". The number of "Filtered Connections" in AD can be found in the Operations tab under Management Agent Operations.
In the screen below you can see that my filters in the Management Agent filters out 361 accounts.
These accounts will be deleted from Office 365 when the export to Office 365 completes.
( CAUTION, This will also delete the corresponding Mailbox )
If you click the number, you can verify the accounts that will be deleted.

When the Full import and Sync is completed, we need to do a Full Confirming Import and export to Office 365 because we want the changes to end up in Office 365.
Do this by right clicking the "TargetWebService" Management Agent en choosing "Run".
Choose the "Full Confirming Import" and click OK.

When the Full Confirming Import completes, we need to do an Export to Office 365.
Do this by following the above steps again, not choosing for the Confirming Import but the Export.
Click OK.
When the Export completes, the accounts and corresponding mailboxes will have been deleted from Office 365. You can confirm this on the management portal under the users tab ( )
My configured filters deleted 359 accounts in Office 365 as can be seen below.

I hope this helps cleaning up your users in Office 365, it was pretty helpfull to us!
More Office 365 tips soon!

woensdag 12 oktober 2011

TMG / ISA configuration for Exchange 2010 and Office365 Rich Coexistence

I ran into an issue when moving mailboxes from my on-prem server to Office 365
First, I thought it had something to do with our Exchange configuration, but after several days troubleshooting with MS support, I found out it was a network issue.
Unfortunately, we use TMG. And as there is NO documentation about configuring TMG for Exchange 2010 and Office 365 Rich coexistence, it was quite a challenge.
But with some trial and error, I managed to get things working.

First of all, this was the error I got when moving the mailboxes from on-prem to the cloud.
The error is quite generic, and had multiple resolutions according to the community.
Unfortunately, I did not find my resolution on the community.

Because the error is quite generic, I decided to run the command in powershell.
To do this, open a normal powershell window.
We need to connect to Office 365 remote powershell, to do this run the following commands.

Type in your Office 365 admin credentials and run the following.

Then, you need to run the same command as the GUI does, but with minor changes.
Here I use the -identity command instead of the Mailbox Guid.

You notice that powershell gives a much more specific error than the GUI.
As the error has something to do with authentication, I checked the logs from TMG.
In the logs I found the below error.

This indicated there is something wrong with our publishing rules.
After some trial and error, I found out that I needed to change the authentication delegation for  the outlook anywhere rule.
I changed the authentication delegation to "No delegation, but client may authenticate directly".
When you select the delegation method No Delegation, but client may authenticate directly, the user's credentials are passed to the destination server without any additional action on the part of TMG Server. The client and the destination server then negotiate the authentication.

Save your TMG / ISA configuration and re-run the move-mailbox command from the remote powershell.
In my case, the mailbox move was succesfull.

You can do a Get-moverequest to show the status of the move.

Another problem solved, but.... certainly not the last :)

donderdag 6 oktober 2011

Useful script to export OCS / Lync telephone nr's from AD

A couple of days ago I was asked if I could export all the telephone numbers from AD used by OCS.
As far as I know OCS does not have this capability out of the box ( unfortunately ).
Using my friend 'google' did not find a usable script either.

With some trial and error I managed to create a scipt to export al the numbers to a csv. ( Actually its not really a script but a single line :) )

I used the free powershell commands for Active Directory by Quest. U can probably get the same results with standard powershell, but I found more useful examples for the Quest powershell.
The powershell command for AD by Quest can be downloaded here.

I downloaded the 64 bit MSI version which is about 33 MB.

After installation, the ActiveRoles Management Shell for Active Directory can be found in the start menu under Quest Software.

The attribute we want to export is msRTCSIP-Line.
This attribute contains the telephone number configured in OCS or Lync.
We want powershell to show us all the users where this attribute had a value.
For this we use an Ldap filter for the attribute msRTCSIP-Line and use a wildcard for a value.

Output of this command gives us a list of users where the attribute msRTCSIP-Line had a value.
But what we want is to see the users displayname and the number for that user.

To accomplish this we have to use a couple of extra parameters.
First, we want to include the value of the attribute msRTCSIP-Line.
So we use the parameter -includedproperties to include the value of the attribute.
Second, we select which attributes we want to show in our list, and last we tell powershell to show the output in a list.
In this example I chose only the displayname and the telephone number to be shown in our list.
U can add / set every attribute u want to show, for example u can add the officelocation or OU.

When performing the command you will see the output on your screen.

To export the values to a csv, we have to replace the | fl for an | Export-Csv -path {path}
If we want to save the csv to c:\scripts\telephonenrsOCSusers.csv for example, we add | Export-Csv -path c:\scripts\telephonenrsOCSusers.csv.

Our final command should look like this.

And there you have it, the csv is saved in the chosen folder.

For the copy pasters amung us :

Get-QADUser  -LDAPFilter '(&(msRTCSip-Line=*))' -IncludedProperties 'msRTCSIP-Line' | Select-Object displayName, msRTCSIP-Line, physicalDeliveryOfficeName | Export-Csv -Path c:\scripts\telephonenrsOCSusers.csv


woensdag 5 oktober 2011

Error when making new federation trust with Microsoft Federation Gateway "The remote name could not be resolved: ''".

A while ago we started our migration to Office 365.
We planned to move to a Hybrid deployment of Exchange 2010 and Office 365.
During the deployment we came across a problem when making a federation with the "Microsoft Federation Gateway".

When running the "New Federation Trust" wizard the Exchange EMC prompted the error below.

The specific error is : "The remote name could not be resolved '' "
A ping to this name resulted in the same error.

On the Office 365 community they referred to the Office 365 Readyness Tool, which checks connectivity with the Microsoft Online Federation Services Endpoint. ( and does several other cool things )
Running the readyness tool did not make the issue any easyer....

It connected succesfully...

Googling the error i found this :
IIRC you need connectivity on port 443 to at least,,

Notice the -P in Unfortunately, the part in the cmdlet is not changeable. It is a static entry that comes from somewhere.

At this point I contacted Microsoft Support.
Several days and an escalation later.... the issue got resolved.

I did not use the EMC to run the commands, but I used the Exchange Management Shell.
First, copy the thumbprint from the EMC error, u need this in the New-FederationTrust cmdlet.
Then open the Exchange Management Shell ( elevated )
Run the command below, and replace the 'thumbprint' with the thumbprint you copied earlyer.

New-FederationTrust -Name 'Microsoft Federation Gateway' -Thumbprint 'thumbprint' -MetadataUrl

You wil notice the command is succesfully run, and the federation with the Microsoft Federation gateway is made.

This can be confirmed by opening the EMC and click on Organization Configuration.
On the right side you see a federation trust with the federation gateway.

Once the federation was made I could follow the rest of the steps in the Exchange deployment assistant.

Here are some url's that might come in handy when deploying Office 365/:
Office 365 readyness tool:
Exchange / Office 365 deployment assistant:
Info on hybrid deployments:

Stay tuned, I have a feeling this is not the last error I face when migrating to Office 365


Hi Everyone!
Welcome to my blog.
In my job as support engineer I work with a lot of different Microsoft products, and mostly have to troubleshoot them.
Therefore this blog will probably be used to place solutions to problems I came across.
And off course, everything that may come in handy to fellow support engineers.

I hope you enjoy! And feel free to ask questions.
Kind regards,
Harm-Jan van Tiel