AnotherUCBlog > Exchange, S4B, O365

Share my findings in the Microsoft unified communication world



EXCHANGE/SFB/UM – Callee voicemail language issue

Hello all,

I had an interesting behavior found by customer recently, he tolds me that when he is reaching the voicemail of one of his user (skype call), voicemail language is in English no matter the UM dialplan…

When I tried to call the user from my mobile, I got the voicemail in the right language (french in our example).

I performed multiple tests and got those results :

  • Internal Skype call -> wrong voicemail language
  • Skype call from federated partner -> right voicemail language
  • PSTN call -> right voicemail language

I compared the Skype for Business logs between internal call and federated partner call and found no difference, the same UM diapl plan was called…

Then I finally found that it was due to the caller mailbox language ! If the caller is having an Exchange mailbox in English then he will reach a voicemail in English.

So this is not an issue but it is per design !


EXCHANGE – X-OWA-Error: Microsoft.Exchange.Data.Storage.StorageTransientException


New day, new problem !

Some users for an unknown were not able to connect to OWA and Outlook suddenly, I never had time to find why unfortunately…

The error in OWA was : X-OWA-Error: Microsoft.Exchange.Data.Storage.StorageTransientExceptiontransienterrorexchange2013

What I did to correct the issue was simply to modify one digit  of the legacyExchangeDN, the last part which is random.

/o=blabla/ou=exchange administrative group (fydibohf24spdlt)/cn=recipients/cn=ef520295b5ab4cc3949fd9e06b7b6285-dbrooks


/o=blabla/ou=exchange administrative group (fydibohf24spdlt)/cn=recipients/cn=ef520295b5ab4cc3949fd9e06b7b6287-dbrooks

Hop this will save time in case it happens to you



O365 EXCHANGE – Powershell connexion to Exchange Online and Exchange On-Premise in the same console

Hello everybody,

Today I had to make a script to compare the Distribution group members between our on-premise environment and the cloud to bee sure that they all are consistent.

The problem I ran into was that the powershell command to get the group members (Get-DistributionGroup) is the same on local Exchange and Exchange Online, so I had to connect/disconnect from each one each time I parse a new Distribution Group, which is taking time and resources…

After some search, I found that in the command “Import-PSSession” use to connect the Exchange (cloud and on-prem) environment, you can use the parameter “prefix” which will be used to make the difference between the on-premise commands and cloud commands.

A bit difficult to explain, here is an example :

Here is how you will create the connection :

# Exchange Online connexion
$ExchangeOnlineSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential (Get-Credential) -Authentication Basic -AllowRedirection -ea stop
Import-PSSession $ExchangeOnlineSession -AllowClobber -Prefix “Cloud” -ea stop

# Exchange On-prem connexion
$LocalExchangSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri “http://$ExchangeServer/powershell/” -Credential (Get-Credential) -Authentication Kerberos -ea stop
Import-PSSession $LocalExchangSession -AllowClobber -Prefix “Local” -ea stop
Set-LocalAdServerSettings -ViewEntireForest $True -ea stop

Now if you want to get the list of mailboxes in the cloud, you have to type this :


If you want to get the list of mailboxes in your local environment, just type this :


Easy !!!

This, decrease my script time execution from 35 min to less than 5 minutes !

Enjoy 😉

O365 EXCHANGE – AutoArchive to pst and Online/in-Place archive

Hello everybody,

You maybe never pay attention of it but when you enable the online or in-place archive and assign a retention policy that move emails older than a certain date to a mailbox. The AutoArchive to pst feature of Outlook (at least 2010 version) disappear (You cannot turn it on but also cannot turn it off (graphically only)).

If this feature is still displayed even an archive is enabled on the account, check the following things :

  1. Ensure that you assign a retention policy that automatically move items to the archive
  2. Ensure that the retention policy has been applied by the MRM process. To verify, follow this :
    1. Open OWA with the intended account
    2. Click on the gear (up – right) and select options
    3. In the “mail” section, select “retention policies”
    4. You should get something like this :


If it is empty then the MRM process did not yet apply the retention policy. you can force it by launching the powershell command “Start-ManagedFolderAssistant”.

Also ensure that you have “Default Archive” retention policy tag, if it is not the case, you need to correct your retention policy.


O365 – OWA Error “We can’t get that information right now. Please try again later.”

Hi Guys,

A user told me that he had an issue to access a shared mailbox via OWA but there was no issue to open it via Outlook…

When accessing with OWA, he got that error :


The user was not having a permission issue as he was able to access it with Outlook and I could with PowerShell that he has FullAccess permission on it.

I gave myself Full Access on that shared mailbox and I got the same error…

After googling a bit, I found that this error was really generic and found multiple solutions like if there was a moverequest flag you could get that error but this was not the case.

Then I saw that the principalsmtpaddress was having an “&” character, so I replaced the email address in the URL by an alias without any special character and… I was able to access it !

The moral of the story, beware of the special characters !

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”

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).

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 ↑