mail = email@example.com
mailNickName = internal.username (should be the same value as samAccountName)
targetAddress = SMTP:firstname.lastname@example.org
proxyAddresses = SMTP:email@example.com
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 https://outlook.office365.com/powershell-liveid/ -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 :
This, decrease my script time execution from 35 min to less than 5 minutes !
Following the article on this new feature, you maybe now want to give access to someone to it and only to it.
This cannot be done via the permissions part of the compliance center, it is indeed in the Exchange Online RBAC permissions.
The cmdlet Search-UnifiedAuditLog is part of the Exchange Online cmdlets.
To give users ability to use that cmdlet you need to assign them the role “View-Only Audit Logs”. Then those users will have to go to “https://protection.office.com/” and they will be able to perform their search.
Have a good day 🙂
If I say that you can now audit and get reports of modifications done in O365 like licenses modification ! That would be great, isn’t it ? This is now the case, thanks to the feature called “O365 Audit log report”.
By default, this feature is turned off, to enable it, follow this steps :
This should take around 2 hours to be effective.
Now to search for any modification done on licenses :
This audit and report feature can also be used for Exchange Online and Sharepoint reporting like modification done a document hosted in a personal Onedrive storage.
The picture show modifications done on an excel file hosted in Onedrive, one modification has been done by an internal user and the other has been done by an external user.
You can audit the following solutions :
Just to let you know :
You can also perform your search using Powershell with the Search-UnifiedAuditLog cmdlet (https://technet.microsoft.com/library/mt238501(v=exchg.160).aspx)
You can get more information regarding this feature on this page https://support.office.com/en-us/article/Search-the-audit-log-in-the-Office-365-Protection-Center-0d4d0f35-390b-4518-800e-0c7ec95e946c?ui=en-US&rs=en-US&ad=US
En joy 🙂
Today, I have started to use the new “PST import” process for O365. It is much quicker and reliable than using Outlook.
Here is how to use it :
If a folder with the same name exist, the process will merge and not create duplicates.
It is not as easy as it was with an on-prem Exchange but it is good that Microsoft proposed this workaround.
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 !
In Exchange/O365, there is multiple ways to set an auto-forward to an external email address :
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 :
To create the remote domain, use the following command (AutoForward is enabled by default) :
“New-RemoteDomain -Name ExternalDomain -DomainName somedomain.com”
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…
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 (https://technet.microsoft.com/en-us/library/Dd979780(v=EXCHG.150).aspx).
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.
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).