The difference between supportability and patching


This came up at the MVP Summit and we, the MVPs, wanted to re-iterate the difference between supportability and patching commitments from Microsoft.

Originally posted on Paul's Down-Home Page:

I’m at the annual MVP Summit this week, and everything we hear and see is pretty much NDA (except for pictures of Flat Tony). However, we just had a really interesting discussion that I think is safe to abstract here.

A couple years ago I wrote a post about what it means to be supported or unsupported. What I wrote then still stands: when Microsoft says something is unsupported, there can be multiple reasons for that label, and you do whatever-it-is at your own risk.

Microsoft’s support policy for Exchange 2013 can be summed up as “N-1″: when they release a new cumulative update (CU) or service pack, that version and the previous version are considered to be supported. So, in the fullness of time, when we get Exchange 2013 CU7, then CU6 and CU7 will be the officially supported versions.

It’s very clear that there’s a lot…

View original 168 more words

Posted in Uncategorized | Leave a comment

Come join the Exchange 2013 information sharing Facebook Group!

This group,, was created over two years ago and has grown to over 4,000 members and over 1,000 post, a year ago it had just over 600 members! The focus of this group is to share information about Exchange 2013, with a bit of leeway given for Exchange 2010 and Office 365 related items.

So what does “information sharing” mean? This mainly includes people sharing blog posts they’ve created, or ones they have come across that they feel are worth sharing. It also includes some basic architecture and functionality questions and discussions. What it DOES NOT include is support or help on issues. Facebook is a poor platform for providing support, in addition on the Microsoft TechNet forums people, like my fellow MVPs get credit for answering questions. These credits help them keep their Microsoft MVP status. So for support type questions goto the Microsoft TechNet forums on Exchange. Therefore, support questions\posts in most cases are deleted, as are any off topic or posts with little to no value. We, the admins of this groups, work hard to keep out the spammers and keep the noise to a minimum. Since this group is very focused there are normally less than a few posts per day in this group.

As you will see the most common poster and fellow group admin (Exchange blogger, writer, etc) is Tony Redmond, who runs two different blogs. Many other Microsoft Exchange MVPs and non-MVPs post links to their articles here also. So if you are looking for some of the latest blog posts and topics on Exchange 2013 check out this Facebook group. If you are a content creators and want to share your Exchange 2013 related content come join the group and feel free to post to it!

Disclaimer: This is an unofficial Microsoft Exchange group. This group is managed by independent Exchange experts. It is NOT an official group by Microsoft and is managed by individuals in their personal time. It is not supported, managed, or moderated by Microsoft in any official capacity. For official support please use TechNet forums or contact Microsoft PSS (Open a tickets from the web).

In the near future we will be activating another Facebook group that will focus on Exchange vNext (version after 2013) and Office 365. Almost all info on vNext is currently under NDA, so nothing to share about it yet. Once this info starts to become public we will then make this other group visible and share it in the current group.

Posted in Exchange, Facebook | Tagged , | Leave a comment

Exchange 2013 CU6, 2010 SP3 RU7, & 2007 SP3 RU14 released & Known Issues

9/16/14 Update: Chrome 37 issue added
9/2/14 Update: More known issues added
8/31/14 Update: Do NOT install 2013 CU6, when co-existing with Exchange 2007, until you have this hotifx: KB2997209 or if you have or want to setup a hybrid relationship with O365 until you have KB2997355. See known issues for more details.
8/29/14 Update:  Known Issues added below. Microsoft released new updates packages for Exchange 2013 CU6 (2961810), 2010 SP3 RU7 (2961522), & 2007 SP3 RU14 (2936861) today. For full details see the Exchange Team’s EHLO post:

2013 CU6                   Download | KB2961810 | EHLO Post
2010 SP3 RU7            Download | KB2961522 | EHLO Post
2007 SP3 RU14          Download | KB2936861 | EHLO Post

Like all CUs for 2013 this one is also a full version of Exchange that can be installed as a 1st time install or will upgrading an existing install of 2013. Key updates in 2013 CU6 are the increase of Public Folder scalability to 100,000 folders, more info here, and a fix for the issue with the Hybrid Configure Wizard (HCW) failing on 1st run or when attempting to modify the settings, see KB2988229 for more info on the HCW issue. Like many of the CUs, CU6 also updates the AD schema. For more info on 2013 CU6 see Tony Redmond’s post here: Like all CU/RUs these contain the recent fixed and security updates, in additional all three contains the latest DST updates. I will add a known issues section to this post when I come run into or hear about issues with these updates.

2013 CU6 Known Issues:

Posted in Exchange | Tagged , , | 3 Comments

Exchange 2013 POP3 service drops connections fix

At my current client they are using POP3 and we are in the process of setting up Exchange 2013 servers to act as hybrid servers for their Office 365 migration.

So after setting up the servers I tested all protocols, then a day or so later I noticed that POP3 was showing down on the Kemp NLB. When I did TELNET test to port 110, from a remote machine, using the FQDN or IP the connection was dropped after a few moments, without returning any text.

I then tried from the Exchange server [2013 CU5, multi-role, 2 NICs (iSCSI and Pubic), POP bindings] itself and had the same results. I then tried and localhost with TELNET and those worked. So the service was working, but not as expected.

I tried rebooting and resetting several settings on the PopSettings and searching for this issue on-line, but came up empty. So finally went to the TechNet Exchange Server 2013 – Outlook, OWA, POP, and IMAP Clients forum and searched on “pop connection” and found this post: POP works via localhost but not from other networked machines, which included the “fix.”

The issue was that the “State” of the PopProxy component was set to Inactive:

[PS] D:\>Get-ServerComponentstate -Identity SRVDENEX01

Server Component State
—— ——— —– ServerWideOffline Active HubTransport Active FrontendTransport Active Monitoring Active RecoveryActionsEnabled Active AutoDiscoverProxy Active ActiveSyncProxy Active EcpProxy Active EwsProxy Active ImapProxy Active OabProxy Active OwaProxy Active PopProxy Inactive PushNotificationsProxy Active RpsProxy Active RwsProxy Active RpcProxy Active UMCallRouter Active XropProxy Active HttpProxyAvailabilityGroup Active ForwardSyncDaemon Active ProvisioningRps Active MapiProxy Active EdgeTransport Active HighAvailability Active SharedCache Active

A quick call to Set-ServerComponentState to mark this component Active fixed the issue:

Set-ServerComponentState -Identity SRVDENEX01 -Component PopProxy -Requester HealthAPI -State Active

After doing this POP started responding as expected, using any valid hostname or IP address.

Like the user who posted to TechNet, I would also like to know why the health check failed and marked the PopProxy as inactive. I will research this further and if I find anything I will update this post.

Posted in Exchange, Microsoft, Technical | Tagged | 10 Comments

Script: Set-UPN-O365.ps1 – Sets UPNs on-premises and in Office 365

I’m working with a client who is migrating to Office 365 and we ran into the issue where users’ UPNs do not match their primary SMTP address, nor was it included as an SMTP address on their mailboxes.  In older, and maybe some current versions, of Android & iPhone devices if the user’s UPN didn’t match their primary SMTP address Autodiscover would fail. The user would then be prompted to put in the server name and login info.

With Office 365 the users must login with their UPN (be default), so its extra important that their UPN is their e-mail address. For my current client this was the issue we had to solve before we migrated to O365, once we migrate the users would need to login with their UPN. But their UPN was <samaccountname> and their Email Address Policy (EAP) in Exchange did not include this. Therefore, it would be confusing to users to tell them to login with their current UPN. In addition, since DirSync was setup months ago their UPN was already set in Office 365. With DirSync setup and a Hybrid configuration UPN updates made on-premises are not replicated to Azure AD (Office 365 AD). So I created the script below to take the PrimarySMTPAddress of a mailbox and set it as the UPN on-premises and in the cloud. I also worked my client to start using a create user script, like the one I posted here:

  • This script was recently created, and with all of my scripts posted to my the blog code may not be updated, but they are updated on on my scripts website (
  • If you find bugs or have questions comment below

Usage: ./Set-UPN-O365.ps1 <filter> [<SearchBase>]

  • Where <Filter>, required, can be any filter supported by the Get-AdUser cmdlet, see this article for examples.
  • Where [<SearchBase>], optional, can be the path to an OU to limit the results of the search
  • Example: ./Set-UPN-O365.ps1 * -SearchBase “OU=US,DC=Company,DC=Com”
    • This would return all users under the US OU

 Required Changes

  1. Install MS Online Services Sign-In Assistant ->
  2. Install Windows Azure PowerShell  ->
  3. $LocalDomain = “COMPANY”
    • Used to display the domain being updated
    • I might eliminate this in a future version by getting this attribute from the AD
  4. $UPNSuffix = “”
    • Used to fill in the default login to O365
  5. $MakeChanges = $False
    • If set to the default of $False changes will only be logged to the screen and Set-UPN-O365.log file
  6. $UpdateO365 = $True
    • If set to $False changes will not be made to Office 365, just logged. $MakeChanges must also be set to $True for changes to be made to O365.

# For more details see
# This script will set the on-premises UPN and Office 365 UPN value for a user
# to their PrimarySMTPAddress. DirSync/Azsure AD Sync will not sync UPN changes
# from on-premises to Office 365. So this script connects to O365 to make the 
# change directly.
# Created 7/11/2014 | Last Updated 8/13/2014
# Source:
# Usage: ./Set-UPN-O365.ps1 <SamAccountName>
# Where: <SamAccountName> is the user you wish to update
	[Parameter(Mandatory = $true)]

$LocalDomain = "COMPANY"
$UPNSuffix = ""

# Requires MS Online Services Sign-In Assistant ->
# Requires above, Windows Azure PowerShell required to update Office 365 ->
# For Filter examples see:

$MakeChanges = $False
$UpdateO365 = $True
$LogFile = "Set-UPN-O365.log"

If (!$MakeChanges) {Write-Host "MakeChange is set to False, changes will not be saved" -ForegroundColor Yellow}
If (!$UpdateO365) {Write-Host "UpdateO365 is set to False, changes will not be saved to Office 365" -ForegroundColor Yellow}

Import-module ActiveDirectory
If ($UpdateO365) {
	Import-Module MSOnline
	If (!$Global:O365Credentials) {
		write-output "Enter credentials for an org admin account in Office 365."
		$Global:O365Credentials = $host.ui.PromptForCredential("Need Office 365 credentials", "Please enter your user name and password.", "$env:username@$UPNSuffix", "UPN")}
	connect-msolservice -credential $Global:O365Credentials

If (!$SearchBase) {$SearchBase = $(Get-ADDomain).DistinguishedName}

Write-Host "Getting users under [$SearchBase] with a Filter of [$Filter]`n" -ForegroundColor Green
$Users = Get-ADUser -SearchScope Subtree -SearchBase "$SearchBase" -Filter $Filter  -Properties mail

"Local account: $env:username | Office 365 Account: $($Global:O365Credentials.UserName) | Started: $(Get-Date -f "MM/dd/yyyy HH:mm:ss")" | Out-File -Append $LogFile

$Users | ForEach {
	$ADUser = $_
	If ($($ADUser.Mail)) {
		$PrimarySmtpAddress = $ADUser.Mail
		$SamAccountName = $ADUser.SamAccountName
		$CurrentUPN = $ADUser.UserPrincipalName
		Write-Host "Updating: $LocalDomain\$SamAccountName" -ForegroundColor Cyan
		"$SamAccountName, $PrimarySmtpAddress, $CurrentUPN" | Out-File $LogFile -Append
		If ($MakeChanges) {
			If ($ADUser.UserPrincipalName -ne $PrimarySmtpAddress) {
				Write-Host "`t Local UPN: $CurrentUPN | New UPN: $PrimarySmtpAddress"
				Set-ADUser $ADUser.DistinguishedName -UserPrincipalName $PrimarySmtpAddress
			Else {Write-Host "`tLocal UPN already matches"  -ForegroundColor Green}
			If ($UpdateO365) {
				$O365User = $Null
				Try {$O365User = Get-MsolUser -UserPrincipalName $CurrentUPN }
				Catch {
					If ($_.Exception.Message -notlike "*User Not Found*") {
						Write-Host "User with UPN of [$CurrentUPN] was not found and will not be updated." -ForegroundColor Red
				If ($O365User) {
					If ($O365User.UserPrincipalName -ne $PrimarySmtpAddress) {
						Write-Host "`tOffice 365 UPN: $CurrentUPN | New UPN: $PrimarySmtpAddress"
						Set-MsolUserPrincipalName -UserPrincipalName $CurrentUPN -NewUserPrincipalName $PrimarySmtpAddress
					Else {Write-Host "`tOffice 365 UPN already matches"  -ForegroundColor Green}
		} # IF $MakeChanges
	} # IF Mail
} #ForEach

Posted in Exchange, Microsoft, Script, Technical | Tagged , , | 1 Comment

Windows Update KB2881011 breaks Outlook 2013 access to archived mailboxes

8/21/14 Update: Microsoft released KB2889859 which fixed this issue for Outlook 2013. Click-to-run has also been updated to 15.0.4641.1003.

8/14/14 Update: KB2881011 has been pulled, but the Click-to-run (Office 365 version of Outlook) update has NOT been pulled and is still affected as of 8/14.


An issue has been discovered in the August 12, 2014, update for Microsoft Outlook 2013 that prevents some users from opening archive folders. We have removed this update from availability until we have a fix. In the interim, you can restore access to archived folders by uninstalling this update. We will add a download link to this article for the new update as soon as it is available.

Original post: (With updates being made as needed)
This update causes Outlook 2013 to fail to open archive mailboxes on Exchange, maybe only on Exchange 2013 CU5 but probably on SP1/CU4 too I would suspect.

When a user, with this update, tries to access their archive mailbox they will get the following error:

The set of folders cannot be opened. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance. 

This update KB2881011 was just released via Windows Update on 8/12/2014, it updates Outlook to 15.0.4641.1001. The issue also occurs in the latest Office 365 Click-to-run version 15.0.4641.1002. After removing this update access will work again.

This is another example of why you should test patches and deploy them to a pilot set of users, using something like WSUS, before deploying them to all users. Want another example, MS14-045 aka KB2984615 can cause BSOD per this article:

Confirmed Affected

  • Outlook x64 w/ KB28810011 (15.0.4641.1001) w/ mailboxes on Exchange 2013 SP1 CU5
  • Outlook x64 w/ KB28810011 (15.0.4641.1001) w/ mailboxes on Exchange Online (Office 365)
  • Outlook x64 Click-to-run version 15.0.4641.1002 w/ mailboxes on Exchange 2013 SP1 CU5
  • In both case Outlook was connected via Outlook Anywhere (RPC/MAPI over HTTPS), not via MAPI over HTTP.

Confirmed NOT affected

  • Outlook x64 Click-to-run version 15.0.4641.1002 w/ mailboxes on Exchange 2010 SP3 UR6
  • Outlook x86 (32-bit) w/ mailboxes on Exchange Online (Office 365)
    • This indicates it might just be an issue with the x64 version of the update

More details on Tony Redmond’s post here:

This issue 1st was posted on the Exchange 2013 Facebook group I manage here: and in the TechNet forums by Jim Collins.

  • Note: The Facebook group should NOT be used for support, it is an information sharing group. Normally all support questions are referred to TechNet then deleted from the group.
Posted in Exchange, Technical | Tagged , | 6 Comments

Exchange 2013 OWA -> 2010 : “something went wrong” issue

Ran into this issue after setting up and configuring two new Exchange 2013 CU5 servers when 2010 SP3 RU6 based mailbox users attempting to login into OWA via Exchange 20130 OWA.

This is probably one of the most useless messages in Exchange, yeah there were many bad ones in earlier versions I know, but really disappointed Microsoft couldn’t provide a bit more troubleshooting information than this partial sentence.  Nothing in event or IIS logs, which I found at least either.

Here’s the whole message you get in OWA 2013 when you run into the problem I did:

EX2013-OWA Error

Users, only test users at this phase of the deployment luckily, who are on Exchange 2010 would get this error when they went to the testing URL ( for Exchange 2013 OWA access.  After they logged into they would get this error, but the browser would continue to act like it was loading the page.

IIS logs on 2013 didn’t contain any errors:
2014-08-12 18:14:59 POST /owa/auth.owa &CorrelationID=<empty>;&cafeReqId=<cut>; 443 zEX20.Test@ Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0) 302 0 0 343

Nor did the HttpProxy logs:
2014-08-12T19:14:37.044Z,e4ab9b1b-9483-4f82-9d0b-e91f2e7b1ecf,15,0,913,7,,Owa,,/owa/auth.owa,,FBA,True,COMPANY\ex20test,,Sid~S-1-5-21-<cut>,Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko,,DCOCEXC220,302,,,POST,,,,,WindowsIdentity,,DCOCEXC020,388,164,,,,72,1003,,0,229;,229,90;48;9;,147,376,,0,1109.4356,4,,,,,,,,,28,1032,0,,1036,,1108,1108,,,BeginRequest=2014-08-12T19:14:35.935Z;CorrelationID=<empty>;ProxyState-Run=None;ServerLocatorCall=c03fc9f8-0322-4166-ba65-e51ddbaa4c24;DownLevelTargetHash=0/0/2;;ResolveCasLatency=31;ProxyState-Complete=CalculateBackEnd;EndRequest=2014-08-12T19:14:37.044Z;I32:ADS.C[DCOCADC007N]=1;F:ADS.AL[DCOCADC007N]=0.9467;I32:ATE.C[]=9;F:ATE.AL[]=1.666667;I32:ATE.C[]=1;F:ATE.AL[]=93;I32:ADS.C[DCOCADC006N]=7;F:ADS.AL[DCOCADC006N]=3.064757;I32:ADR.C[DCOCADC006N]=3;F:ADR.AL[DCOCADC006N]=1.140667,

After trying many things, links to a couple at the end, I got it working after enabling Windows Authentication in IIS on the OWA & ECP virtual directories on the Exchange 2010 CAS servers.  I should have checked that 1st! After making this change you will also need to recycle the MSExchangeOWAAppPool & MSExchangeECPAppPool Application Pools to make it take effect immediately.

This left Basic & Windows Authentication enabled on the OWA & ECP VDs on 2010 in IIS and just basic on Exchange 2013.

Output from Get-OWA\ECPVirtualDirectory after fixing the issue:

Get-OwaVirtualDirectory | fl name, server, *auth*

Name                          : owa (Default Web Site)
Server                        : DCOCEXC011 (2010 server)
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : True
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
ExternalAuthenticationMethods : {Fba}

Name                          : owa (Default Web Site)
Server                        : DCOCEXC220 (2013 server)
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}

Get-EcpVirtualDirectory | fl name, server, *auth*

Name                          : ecp (Default Web Site)
Server                        : DCOCEXC011 (2010 server)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : True
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
ExternalAuthenticationMethods : {Fba}

Name                          : ecp (Default Web Site)
Server                        : DCOCEXC220 (2013 server)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}

Related issues, but not the solution for my issue:

Posted in Exchange, Technical | Tagged | 7 Comments