AnotherUCBlog > Exchange, S4B, O365

Share my findings in the Microsoft unified communication world


August 2015

Lync – Import contacts from a user account to another one


Usually, we need to perform an export/import of the contacts of a user for a migration purposes.

Today, someone asked me to delete a Lync account and enable a Lync Account on a new AD account and migrate the contacts from the old one to the new one.

This is something possible with the commands “Export-csUserData” and “Update-csUserData”. Don’t use the command “import-csUserData” because it will not work.

The difference between the two commands is that “import” replace while “update” just append the data (which is not a problem as the destination is new).

The process is like this :

  1. Launch the command “Export-CsUserData -PoolFQDN poolname -FileName -UserFilter UserSipAddress
  2. A zip is created containing the data
  3. Launch the command “Update-CsUserData -FileName -UserFilter UserSipAddress
  4. The contacts are now in the new Lync account

If the user also changed his SIP address, then there is an extra step where you need to edit the file called DocItem in the zip file before launching the command to update.

  1. Open the zip file created
  2. Extract the file DocItemSet.xml
  3. Open it with text editor and replace any occurence of the old SIP address with the new one then save it.
  4. Replace the file previously edited in the zip file and launch the update.

Exchange – Set a forward to an external email address

Hi guys,

In Exchange/O365, there is multiple ways to set an auto-forward to an external email address :

  • Create a contact and set a forward on the mailbox (GUI or PowerShell) to this contact


  • Fill the parameter “ForwardingSMTPAddress” on the mailbox with the external email address (Powershell)
    • The command looks like this : “Set-Mailbox MailboxForwardFrom -ForwardingSMTPAddress”
  • Fill the AD attribute “targetAddress” with the external email address (Exchange on-premise only)


The first choice will work for both O365 and Exchange directly. The third one will also work directly in Exchange on-premise.

But the second choice will work directly only on O365. That is because, in O365 the remote domain “*” is already created with the AutoForwardEnabled property so AutoForward will work for any external domains. In Exchange, this remote domain is not created by default so you have two options :

  • You can create a remote domain with “*” and the property AutoForwardEnabled which will enable the auto forward for any external domains
  • You can create a remote domain per external domain in order to control this feature.

To create the remote domain, use the following command (AutoForward is enabled by default) :

“New-RemoteDomain -Name ExternalDomain -DomainName”

EOP – Emails identified as spam do not go to the Junk email folder


Today we encounter a new issue, a user was complaining about receiving a lot of spam in their inbox. He sent me more than ten examples and when looking at the header, all of them were well identified by EOP and should have been moved to the Junk email folder…

X-Forefront-Antispam-Report: CIP:;CTRY:DE;IPV:NLI;EFV:NLI;SFV:SPM;SFS:(2990300002)(438002)(3380300002)(189002)(199003)(107886002)(106466001)(58226001)(2351001)(77156002)(19617315012)(46102003)(81156007)(16236675004)(62966003)(15975445007)(512874002)(450100001)(5002240100001)(84326002)(2920100001)(64706001)(229853001)(4001450100002)(5001960100002)(2160300002)(110136002)(92566002)(5001860100001)(5001830100001)(81686999)(50986999)(4001540100001)(5002050100002)(54356999)(42186005)(19580395003)(189998001)(44706002)(86362001)(87836001)(100156002);DIR:INB;SFP:;SCL:5;SRVR:DB3PR06MB140;;FPR:;SPF:Pass;;MX:1;A:1;LANG:en;

I have also performed a mail trace and it was explicit that the email has been moved to the junk email folder !


After some search, I found that there is a possiblity to disable and also custom the junk email rule for a specific mailbox. This can be done thanks to this command Set-MailboxJunkEmailConfiguration (

After running the command Get-MailboxJunkEmailConfiguration for this user, I have effectively seen that for him the rule was disabled ! Why this was disabled, I don’t really know but I think that this was done before the migration to O365 and this setting is kept during the move.

O365 – Duplicate mailbox Cloud/On-Prem

Hi all,

Today, I received a complain from a user which was not receiving any emails coming from external…

So I checked his account and found that this user had a mailbox in the cloud but also in our Exchange environment ! Of course as the MX records are still pointing to the on-prem, all external emails came on the on-prem mailbox and never been forwarded to the cloud mailbox…

So the only solution I found was to export the on-prem mailbox as a pst using the command new-mailboxexportrequest then disable the mailbox (ensure to keep the proxy addresses and every ms exchange custom attributes before launching the command) and finally enable a mail user (report the proxy addresses and the custom attributes if needed).

O365 – Bypass clutter


MS provides us a way to disable the clutter feature via a simple cmdlet ( but if you have tried it, you have seen that the execution of the command is really long (from 7 sec to 15 sec in our case) and for a large number of mailboxes, it is a bit difficult to manage.

Also, you have no way to check if you already forced the turn off of the feature, the field “enabled” stay at false after execution of the command…

So to be sure that no email are moved to the clutter folder, you can setup a transport rule that will add the line “X-MS-Exchange-Organization-BypassClutter” with the value “true” and the effect will be that the message will not be moved to the clutter folder.

More information on the technet page :

An important thing, I wanted to add is that this line appear only on messages tagged by clutter. So you have to use MFCMapi to test the rule…



Having the “EWS not deployed” issue can cause those issues :

  • Unable to change your profile picture in Exchange
  • Unable to get your voicemail
  • Unable to get your conversation history
  • Unable create contacts in Exchange (unified contact store)


If you are having this issue, try the following things :

  • Try to get your Exchange autodiscover xml with your browser (usually something like : “”)
  • If you can get the xml content without getting an Exchange form authentication, you are good with autodiscover. If you are getting a form, change the setting in your Exchange organization or remove the pre-auth in your TMG rule (external access).
  • Try to access your Exchange web services with your browser (usually something like : “https://EXCHANGE_SERVER_HOSTNAME/EWS/Exchange.asmx”)
  • If you are getting a prompt for authentication, you are good. If you are getting a form then same thing as autodiscover, change the setting in your Exchange organization or remove the pre-auth in your TMG rule (external access).

Indeed, when starting your Lync or Skype for Business client, in order to retrieve the EWS URL it is launching an autodiscover request based on your primary SMTP address which is getting thanks to in-band provisioning process.

LYNC – OWA IM Error “Your instant message couldn’t be delivered”

Update 08/06/2015 : I found another technet page explaining that the same federation route need to be set for every pool in the organization ->


It is also explaining that even you set up only one federation route A/V traffic will go through each respective Edge pool, only SIP, IM will go through the Edge pool set for the federation route.


Some weeks ago, we found that our OWA(O365)-Lync(On-Prem) integration was not working completely.

Here is the status :

  • Presence -> OK
  • IM with someone in the same Lync pool -> OK
  • IM with someone in another Lync pool -> NOK

I was getting this error message :

IM OWA Error message Federation

After troubleshooting with MS, we found that the issue was the fact that we had for each front-end pool a different federation route. Each front-end pool was using it’s own Edge pool for federation and that caused the issue.

This is also wrote in the followed technet page :


O365 – Report users with administrative rights on O365 platform


Now that MS provides us a way to have more flexibility to give admin rights on the O365 platform (, we started to give more and more permissions to more users. So I thought about creating a script to report who is having which rights.

Here is the script :

Don’t forget to fill the fields $Office365Account and $Office365Password with your O365 Admin credentials.

You can get more information on the different roles here :

EOP Hybrid – Ensure spam are moved to “Junk” folder for on-premise users


After that we started to get a lot of users in the cloud, we started to move the MX records to target directly the cloud and then transfer to on-premise environment if the user was not yet migrated.

As soon as we started this task, non migrated users started to complains about receiving a lot of spam in their inbox…

Email headers are showing  that the email is well identified as spam, you can see it thanks to the line below :

X-Forefront-Antispam-Report: CIP:;CTRY:;IPV:NLI;EFV:NLI;SFV:SPM;SFS:(2990300002)(438002)(199003)(189002)(19618635001)(4590100002)(450100001)(23846002)(77156002)(110146008)(18206015028)(15975445007)(62966003)(118296001)(64706001)(19617315012)(2351001)(87836001)(229853001)(46102003)(54356999)(50466002)(50986999)(23676002)(106466001)(551544002)(86362001)(42186005)(92566002)(4001450100002)(19580395003)(5002240100001)(5002050100002)(5820100001)(5001960100002)(189998001)(2160300002)(4001540100001)(5001830100001)(5001860100001)(81156007)(110136002)(107886002)(5210400004);DIR:INB;SFP:;SCL:5;SRVR:server;;FPR:;SPF:Pass;;A:1;MX:1;LANG:en

The thing is that your on-premise Exchange do not take a look at this line and as O365 and your on-premise are not in the same organization, the message is not moved…

To correct MS advise to create a transport rule ( that check the header of each emails to see if he find the value “SFV:SPM” and then increment the SCL value above the SclJunkThreshold value set on-premise.

Be sure that the SCL value that you set in the transport rule is above (equal is not sufficient unlike what is wrote in the technet page) the SCLJunkThreshold one.

Blog at

Up ↑