Fix for Exchange ActiveSync Failures After Migration to Exchange 2013

There’s a bug in Exchange 2013 that causes Exchange ActiveSync to fail for newly migrated users from Exchange 2010. It only affects migrated users who already have a mobile device configured, not new users (i.e., test mailboxes). This issue was discussed in the Exchange Server forums back in August 2013.


The issue occurs because the IIS application pools on the CAS 2013 servers do not automatically detect that the mailbox has been moved to Exchange 2013. When the user’s mobile device connects to CAS 2013, CAS 2013 proxies the user back to CAS 2010 which responds with an error saying the mailbox is corrupt or missing. If you run an Exchange ActiveSync test using ExRCA you will see the X-CalculatedBETarget value reported by CAS2013 is still pointing to the Exchange 2010 server. The problem usually resolves itself in 1-8 hours, depending on the Exchange 2013 build.

The workaround is to manually recycle the MSExchangeAutodiscoverAppPool and MSExchangeSyncAppPool application pools in IIS on all CAS2013 servers.

I wrote a PowerShell script for this called Recycle-AppPools.ps1:

#Recycle-AppPools.ps1
#Jeff Guillet, MCM|MCSM|MVP|CISSP
#Use this script to recycle IIS Application Pools to overcome Exchange 2013 SP1 ActiveSync bug for migrated users

#Get all Exchange 2013 CAS servers
$CASServers = Get-ClientAccessServer | where {$_.WorkloadManagementPolicy -ne $null}

#Loop through each CAS2013 and recycle the IIS App Pools
foreach ($CAS in $CASServers) {
  Write-Host “Recycling App Pools on $CAS…”
  $appPool = Get-WmiObject -Authentication PacketPrivacy -Impersonation Impersonate -ComputerName $CAS -namespace “root/MicrosoftIISv2″ -class IIsApplicationPool | Where-Object {$_.Name -eq “W3SVC/AppPools/MSExchangeAutodiscoverAppPool” }
  $appPool.Recycle()
  $appPool = Get-WmiObject -Authentication PacketPrivacy -Impersonation Impersonate -ComputerName $CAS -namespace “root/MicrosoftIISv2″ -class IIsApplicationPool | Where-Object {$_.Name -eq “W3SVC/AppPools/MSExchangeSyncAppPool” }
  $appPool.Recycle()
}

You will need to run the script after an EAS user or batch of users have been migrated. There is no outage associated with recycling the app pools and it recycles very quickly. A fix is scheduled for Exchange 2013 CU5.



Tips for Connecting to Office 365 using PowerShell in Hybrid Environments

The Office 365 portal and Exchange Admin Console are fairly powerful to allow you to manage your tenant and on-premises environments. But as you are no doubt aware, there are many administrative tasks that require you to use PowerShell.



The sequence you usually find on the web to connect to Office 365 via PowerShell is:

[PS] C:\>$LiveCred = Get-Credential -credential admin@contoso.onmicrosoft.com
[PS] C:\>$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
[PS] C:\>Import-PSSession $Session

If you are in a hybrid environment with Exchange and Office 365 you will discover that both environments have a lot of the same cmdlets, such as Get-Mailbox, Set-DistributionGroup, etc. This causes a conflict when the Office 365 PowerShell cmdlets are loaded within the Exchange Management Shell. You either need to connect to Office 365 PowerShell from a regular PowerShell console (separate window) or you need to use the -AllowClobber parameter, which overwrites the existing EMS cmdlets with the Office 365 versions. This is not ideal if you are working with both on-prem and cloud objects at the same time.

Proxy creation has been skipped for the following command … Use the AllowClobber parameter if you want to shadow existing local commands
I wrote a PowerShell script called Connect-Office365.ps1 that overcomes these conflicts by using the -Prefix parameter with the Import-PSSession cmdlet. The Prefix parameter tells PowerShell to add the specified prefix to all cmdlets it loads from Office 365. For example, if you set the prefix to “cloud” the Get-Mailbox cmdlet for Office 365 becomes Get-cloudMailbox and the Get-Mailbox cmdlet still applies to on-prem. This way you can use both sets of cmdlets in the same EMS console. The script also connects to the MSOLService so you can use the MSOL cmdlets to manage Azure AD.

Connect-Office365.ps1 with “cloud” prefix
Here’s the four line Connect-Office365.ps1 script:
$LiveCred = Get-Credential -credential “admin@contoso.onmicrosoft.com”
 
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session -WarningAction SilentlyContinue -Prefix cloud

Connect-MsolService -Credential $LiveCred

I usually copy the script to the C:\Windows folder on my Exchange servers and my management computer so it can be run from any directory whenever I need it.




The ‘Heartbleed’ Security Flaw – Are You Affected?


(CNN) — A major online security vulnerability dubbed “Heartbleed” could put your personal information at risk, including passwords, credit card information and e-mails.

Heartbleed is a flaw in OpenSSL, an open-source encryption technology that is used by an estimated two-thirds of Web servers. It is behind many HTTPS sites that collect personal or financial information. These sites are typically indicated by a lock icon in the browser to let site visitors know the information they’re sending online is hidden from prying eyes.

Cybercriminals could exploit the bug to access visitors’ personal data as well as a site’s cryptographic keys, which can be used to impersonate that site and collect even more information.

You can use the Heartbleed Test website (http://filippo.io/Heartbleed/) to test your external websites and external-facing web appliances to see if they are vulnerable. I encourage you to make a quick test of your systems ASAP.



Notes on the Windows 8.1 Update for Windows Server 2012 R2

Microsoft has released the Windows 8.1 Update to MSDN subscribers and is due to be released today to the general public. This update also applies to Windows Server 2012 R2 servers and includes some important updates, including one that will be required so that Windows 8.1 and Windows Server 2012 R2 computers will continue to receive important security updates.



The Windows 8.1 Update (no number, as if there will never be another) is actually a series of 6 updates which should be installed in a certain order.  I created an installer batch file that installs the updates for Windows Server 2012 R2 in the recommended order with minimal output.



Copy the following text to Notepad and save it as Install.bat in the same folder as all the x64 patch files:

start /wait Windows8.1-KB2919442-x64.msu /quiet /norestart
start /wait Windows8.1-KB2919355-x64.msu /quiet /norestart
start /wait Windows8.1-KB2932046-x64.msu /quiet /norestart
start /wait Windows8.1-KB2937592-x64.msu /quiet /norestart
start /wait Windows8.1-KB2938439-x64.msu /quiet /norestart
start /wait Windows8.1-KB2949621-v2-x64.msu /quiet /norestart
@echo Please restart the computer now.

And here’s a version for Windows 8.1 x86:

start /wait Windows8.1-KB2919442-x86.msu /quiet /norestart
start /wait Windows8.1-KB2919355-x86.msu /quiet /norestart
start /wait Windows8.1-KB2932046-x86.msu /quiet /norestart
start /wait Windows8.1-KB2937592-x86.msu /quiet /norestart
start /wait Windows8.1-KB2938439-x86.msu /quiet /norestart
start /wait Windows8.1-KB2949621-v2-x86.msu /quiet /norestart
@echo Please restart the computer now.

Once you install the update and restart the computer you’ll immediately notice that the Windows App Store icon is on your taskbar.



Windows App Store is added to the Windows 2012 R2 Taskbar



If you’re running Windows Server 2012 R2 and signed in the the Admin account you’ll find that the Store won’t open and gives the error, “This app can’t open. Store can’t be opened using the Built-in Administrator account. Sign in with a different account and try again.” Doh! Right-click the icon and unpin it from the taskbar to recover that real estate.



This dawg won’t hunt

It’s interesting to see Microsoft slowly unraveling the “Modern UI” to behave more like the desktop UI. They’ve added a power button to the Modern UI desktop so users can easily shutdown or restart the computer and added a search icon because users didn’t intuitively know that they can just start typing to search.