Archive for the ‘Microsoft’ Category

Hybrid Modern Public Folders not working for some users

November 4, 2016 Comments off

Hey! Ran into a strange issue where certain users were not able to access modern public folders on-premise and some users had no issues at all.
The users that had no issues were users that had a mailbox on-premise and then later migrated to the cloud.
The users that had issues were users that were created via the New-RemoteMailbox PowerShell cmdlet.

I was familiar with this issue on Legacy Public Folders but not on Modern Public Folders.

The fix for Legacy Public Folders is that it’s missing the cloud LegacyExchangeDN as an X500 address on-premise
Solution in a simple 1 liner PowerShell script:

Get-Mailbox | foreach {Set-ADUser -Identity $_.Alias -Add @{Proxyaddresses="X500:"+$_.LegacyExchangeDN}}

So after some digging around and talking to the product engineering team and other peers we came to this conclusion:

The issue for the Modern Public Folders is that it’s missing the ExchangeGUID attribute. And how O365 does a lookup for the modern public folders on-premise.
This seems to have been fixed in Exchange 2013 SP1 CU14 (CU 13 and below are still affected) Additionally there were Free/Busy issues as well due to it looking for a non-existing ExchangeGUID.

So there are two solutions here either upgrade all your Exchange 2013 servers to CU14 or run the following PowerShell cmdlet to add the ExchangeGUID property to the users:

$cred = get-credential
$session = New-PSsession -configurationname -connectionuri -allowredirection -authentication basic -credential $cred -verbose
Import-PSSession $Session -Prefix EXO
$formatenumerationlimit = -1

Get-RemoteMailbox -ResultSize Unlimited -filter {ExchangeGuid -eq "00000000-0000-0000-0000-000000000000"} | foreach {Get-EXOMailbox -Identity $_.Alias} | foreach {Set-RemoteMailbox -Identity $_.Alias -ExchangeGuid $_.ExchangeGuid}

Or if you don’t like one liners and like an output into CSV:

$cred = get-credential
$session = New-PSsession -configurationname -connectionuri -allowredirection -authentication basic -credential $cred -verbose
Import-PSSession $Session -Prefix EXO
$formatenumerationlimit = -1

Get-RemoteMailbox -ResultSize Unlimited -filter {ExchangeGuid -eq "00000000-0000-0000-0000-000000000000"} | Export-CSV C:\temp\RemoteMailboxesWithNoGUIDS.csv
$i = Import-CSV C:\temp\RemoteMailboxesWithNoGUIDS.csv
$i | foreach {Get-EXOMailbox -Identity $_.Alias} | foreach {Set-RemoteMailbox -Identity $_.Alias -ExchangeGuid $_.ExchangeGuid}

Categories: Microsoft, Office 365

Exchange Server high cpu usage

April 4, 2013 2 comments

Ever notice that your w3wp.exe is using up all your cpu and pegging at above 90%-99%?
Good chances that iOS devices are hammering it like crazy.
After dealing with this a number of times (thanks Apple) here is a little trick to quarantine device until they are remediated.

in the Exchange Management Shell type the following:

New-ActiveSyncDeviceAccessRule -QueryString “lOS 6.1 10B141” -Characteristic DeviceOS -AccessLevel Quarantine
New-ActiveSyncDeviceAccessRule -QueryString “los 6.1 10142” -Characteristic DeviceOS -AccessLevel Quarantine
New-ActiveSyncDeviceAccessRule -QueryString “lOS 6.1 108143” -Characteristic DeviceOS -AccessLevel Quarantine
New-ActiveSyncDeviceAccessRule -QueryString “los 6.1 10B144” -Characteristic DeviceOS -AccessLevel Quarantine
New-ActiveSyncDeviceAccessRule -QueryString “lOS 6.1.1 108145” -Characteristic DeviceOS -AccessLevel Quarantine

This will effectively put those versions into Quarantine and take them out automatically once they upgrade to a newer firmware version.

Also setting up a recycling schedule or certain limits in IIS before it recycles would also be a good thing to do after this.


Another cause could be the following:

W3wp.exe process consumes excessive CPU and memory resources on an Exchange Client Access server after you apply Update Rollup 5 version 2 for Exchange Server 2010 SP2 which is re-mediated with Exchange SP3



Hide federated user from GAL on Office 365 with no Exchange server On-premises

January 26, 2012 2 comments

While working on a clients environment a RFC came in to hide certain users from the Global Address List as they were no longer working for the company.
Which brings us to a minor set back within full cloud environments; since there was no local exchange server how do I change the attribute for hiding a user?

First thing I tried off the bat was since I do have an Exchange environment running, is add their Exchange Online environment into my management console.
Which works perfectly and if they weren’t federated users (dirsync running locally for SSO) I would not have had this error:















So this brings me to a challenge on how to solve this, which is actually quite simple, I’ll break it down into 8 simple steps for you:

1. Logon to a local DC and make sure you are an Enterprise & Schema Admin.
2. On the same server insert the Exchange 2010 CD (or download Exchange 2010 SP2 and unpack it).
3. Open up a CMD prompt and browse to the CD/SP2 directory.
4. Extend the schema by executing the following command: setup.exe /ps (if this is not sufficient you can also do “setup.exe /PrepareAD” and “setup.exe /pl“)
5. After this is done open up adsiedit.msc and connect to the “Default Nameing Context”
6. Drill down to the user that needs to be hidden and select properties.
7. Find the Attribute called “MsExchHideFromAddressLists” and set it to “TRUE” (if the Attribute is not there yet, wait a few minutes as it may still be being populated/synced over other DC’s)


















8. After the setting is made, connect to your dirsync server and start the DirSyncConfigShell.psc1 to force a manual sync by executing the command “Start-OnlineCoexistenceSync

After this you will find that the user is not longer visible in the GAL.

Good luck!