Archive

Archive for the ‘Exchange 2010’ Category

New IOS issue on Exchange Active Sync

April 22, 2013 5 comments

iOS device users locked out of Active Directory accounts

When a user changes their Active Directory account password, iOS devices prompt for the new password. The user enters in the new password. However, the device does NOT use the new password and continues to use the OLD password, which causes the account to be locked out.

 

STATUS

Apple is aware of this issue, and customers should open an Enterprise level support case with Apple to pursue a fix in iOS.

 

WORKAROUND

On the device, open the Settings panel and edit the profile to force the new password to be used by the iOS device on the next connection.

 

Microsoft’s main Known ActiveSync Issues KB (http://support.microsoft.com/kb/2563324) has been updated to include this issue as issue 2.10.

Advertisements

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!

Office 365: Adding a remote Organization Relationship won’t work

July 7, 2011 1 comment

Hi Everybody!

Whilst in the classroom giving the training Office 365 ignite in a box, the students ran into a problem.
They were unable to create a Remote Organization Relationship.

Here I will explain and show the powershell cmdlets that where used to make it possible.

But first I’ll let you know what the exact error was that they got:

Error:
Exception has been thrown by the target of an invocation

New-OrganizationRelationship -Name 'On-premises' -Enabled $true -FreeBusyAccessEnabled $true -FreeBusyAccessLevel 'LimitedDetails' -FreeBusyAccessScope $null -DomainNames 'yourchilddomain','onprem.yourchilddomain' -TargetApplicationUre 'ExoDelegate.yourchilddomain' -TargetAutodiscoverEpr 'https://yourchilddomain/autodiscover/autodiscover.svc/wssecurity'

 Solution:

Start Windows Powershell
1. $cred = Get-Credential
2. $s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection
3. $importresults = Import-PSSession $s

Optionally you can also type these cmdlets
$importresults.ExportedFunctions.Count
Get-Command -Module $importresults | Out-Host -Paging

4. enable-organizationcustomization
5. New-OrganizationRelationship -Name 'On-premises' -Enabled $true -FreeBusyAccessEnabled $true -FreeBusyAccessLevel 'LimitedDetails' -FreeBusyAccessScope $null -DomainNames 'yourchilddomain','onprem.yourchilddomain' -TargetApplicationUri 'exodelegate.yourchilddomain' -TargetAutodiscoverEpr 'https://yourchilddomain/autodiscover/autodiscover.svc/wssecurity'

  

 
And tadaaaaa there it is!

 
Also I have the following in my public dns server which added to the solution:
Point to your on-premesis Exchange CAS server:
autodiscover.yourchilddomain
exodelegate.yourchilddomain
hosted.yourchilddomain
mail.yourchilddomain
onprem.yourchilddomain

Point to your AD FS 2.0 server:
sts.yourchilddomain

At least this is what was the case for me, they all pointed to the same IP address since I have a TMG server in front of all servers

I hope this will solve your problem too!