Log in



Tags » ‘rollup for Exchange 2010’

Exchange 2010 SP1 Rollup 4 re-released

July 28th, 2011 by

As many of you know the Exchange team released Exchange 2010 SP1 Rollup 4 back on June 22nd.  Well, on July 13th there was a bug identified with the release and they had to pull the release.

Last night the Exchange team re-release Rollup 4 for Exchange 2010 SP1.  Following the release they also posted a update on what happened with the recall of Rollup 4 and what they are doing to help reduce the likelihood of this happening in the future.

As for me, I may wait a week or two before applying it just to be sure it is working correctly.  Not to say I doubt the Exchange team but if you recall Rollup 3 for Exchange 2010 SP1 went through three revisions before they got it right.

Here is a quick read of the Q&A of the update on Rollup 4:

  • Q: What actually triggered the recall?
  • A: While fixing a bug that prevented deleted public folders from being recovered, we exposed an untested set of conditions with the Outlook client. When moving or copying a folder, Outlook passes a flag on a remote procedure call that instructs the Information Store to open deleted items which haven’t been purged. Our fix inadvertently caused the RPC to skip all content that wasn’t marked for deletion because we were not expecting this flag on the call from Outlook on the copy and move operations.
  • Q: Why didn’t you test this scenario?
  • A: The short answer is we thought we did. We didn’t realize we missed a key interaction between Exchange and Outlook. The Exchange team has well over 100,000 automated tests that we use to validate our product before we ship it. With the richness and number of scenarios and behaviors that Exchange supports, automated testing is the only scalable solution. We execute these tests in varying scenarios and conditions repeatedly before we release the software to our customers. We also supplement these tests with manual validation where necessary. The downside of our tests is that they primarily exercise the interfaces we expose and are designed around our specifications. They do test positive and negative conditions to catch unexpected behavior and we did execute numerous folder copy and move tests against the modified code which all passed. What we did not realize is that our tests were not emulating the procedure call as executed by Outlook.
  • Q: Exchange has been around a while, why did this happen now?
  • A: In Exchange 2010 we introduced a feature called RPC Client Access. This functionality is responsible for serving as the MAPI endpoint for Outlook clients. It allowed us to abstract client connections away from the Information Store (on Mailbox servers) and cause all Outlook clients to connect to the RPC Client Access service.    As part of our investigation, we discovered that there was some specific code added to the Exchange 2003 Information Store to handle the procedure call from Outlook using the extra flag. This code was also carried forward into Exchange 2007. But when the Exchange team added the RPC Client Access service to Exchange 2010, that code was not incorporated into the RPC Client Access service because it was mistakenly believed to be legacy Outlook behavior that was no longer required. That, unfortunately, turned out not to be the case. The fact that we were not allowing a deleted public folder to be recovered was masking this new bug completely.
  • Q: Are there other similar issues lurking in RPC Client Access?
  • A: We do not believe so. The RPC Client Access functionality has been well-tested at scale and proven to be reliable for the millions of mailboxes hosted in on-premises deployment and in our own Office 365 and Live@EDU services.
  • Q: What are you doing to prevent similar things from happening in the future?
  • A: We have conducted a top-to-bottom review of the process we use to triage, develop and validate changes for Rollups and Service Packs and are making several improvements. We have changed the way we evaluate a customer requested fix to ensure that we more accurately identify the risk and usage scenarios that must be validated for a given fix. Recognizing the diversity of clients used to connect to Exchange, we are increasing our client driven test coverage to broaden the usage patterns validated prior to release. Most notably, we are working even closer with our counterparts in Outlook to use their automated test coverage against each of our releases as well. We are also looking to increase coverage for other clients as well.

 

 

 

Update Rollup 3 for Exchange 2010 SP1 and Exchange 2007 SP3

March 8th, 2011 by

The Exchange Team today released two new Rollups for Exchange 2010 SP1 and Exchange 2007 SP3.  More detail can be found here - Released: Update Rollup 3 for Exchange 2010 SP1 and Exchange 2007 SP3.

One thing to note are fixes for memory leaks in 2010 which I have seen in the wild.  This has caused some Exchange Servers to crash.  Glad to see this was addressed.   You can find a description of the rollup for 2010 here: http://support.microsoft.com/?kbid=2492690

For the release notes for Rollup 3 for Exchange 2007 SP3 you can go here: http://support.microsoft.com/?kbid=2492691

Have a great day everyone!

Exchange 2010 SP1 Update Rollup 1 Released

October 7th, 2010 by

The Exchange Team announced today the release of Exchange 2010 Sp1 Update Rollup 1. 

The update addresses the following issues:

  • 2028967  (http://support.microsoft.com/kb/2028967/ ) Event ID 3022 is logged and you still cannot replicate a public folder from one Exchange Server 2010 server to another
  • 2251610  (http://support.microsoft.com/kb/2251610/ ) The email address of a user is updated unexpectedly after you run the Update-Recipient cmdlet on an Exchange Server 2010 server
  • 978292  (http://support.microsoft.com/kb/978292/ ) An IMAP4 client cannot send an email message that has a large attachment in a mixed Exchange Server 2010 and Exchange Server 2003 environment
  • 982004  (http://support.microsoft.com/kb/982004/ ) Exchange Server 2010 users cannot access the public folder
  • 983549  (http://support.microsoft.com/kb/983549/ ) Exchange Server 2010 removes the sender’s email address from the recipient list in a redirected email message
  • 983492  (http://support.microsoft.com/kb/983492/ ) You cannot view updated content of an Exchange Server 2010 public folder
  • If you ask me nothing to significant but doesn’t hurt to bring it to your attention. 

    For more information you can check out the Exchange Team Blog.

    Have a great night!

    Exchange 2010 RU 4 released (KB982639)!

    June 18th, 2010 by

    Back on April 22nd you may recall an article I wrote dealing with a Bug identified with Exchange 2010 where there is a “.” in the NETBIOS name (KB981033).  Well last night the MS Exchange Team released Exchange 2010 RU 4.  As part of this rollup there is  a fix for the “.” in the NETBIOS name issue.  I noticed that it wasn’t listed in the KB Article but I did email my contact at Microsoft and he did confirm that this RU does address the “.” in the NETBIOS name.  

    For all of you out there having this problem I strongly encourage you to go and get  Exchange 2010 RU 4 (KB982639) and apply it, after all, it’s what you have been waiting for!

    NOTE:  For those of you who recieved the Interim Update from MS (KB981033) you will need to remove this update prior to installing Exchange 2010 RU4. 

    Have a great day!

    Bug identified when Deploying Exchange 2010 in a domain with a ‘.’ in the NETBIOS name! (KB981033)

    April 22nd, 2010 by

    I was starting to deploy Exchange 2010 for a client today that contained a ‘.’ in their NETBIOS name when I came across a bug.   The majority of organizations will deploy an Active Directory environment using a single name for their NETBIOS domain name.  For example, ‘scottfeltmann.com’ would have a NETBIOS name of ‘scottfeltmann’ or ‘contoso.com’ would be ‘contoso’.  

    I started out by running the Exchange 2010 Pre-Deployment Analyzer Tool.  No issues discovered.  I then deployed the Client Access Server role. No errors were reported during the installation of the CAS.  Upon the completion of the installation of the role I opened up the Exchange Management Console (EMC) clicked on the ‘Microsoft Exchange On-Premises’ option and got the following error:

    Initialization failed

     “The following error occurred when getting user information from ‘domain.com\username’: 

    The operation couldn’t be performed because the object ‘domain.com\username’ couldn’t be found on domaincontroller.domain.com.  It was running the command ‘Get-LogonUser’.

    How odd, this isn’t normal.  I haven’t seen this in any other environment, but then again, I haven’t come across a netbios name with a ‘.’ in it.  At first I checked AD for any issues, thinking maybe there was a replication problem.  I did find one small problems, resolved it, tried again, same result. 

    I then turned to my friend google. 

    Doing some research I came across this article with the same problem: http://www.eggheadcafe.com/software/aspnet/35384695/exchange-2010-period-in-n.aspx  a ‘.’ in the domain NETBIOS name.  Doing further digging I came across this article on StuartP’s blog which describes the issue: http://blogs.technet.com/stuartp/archive/2010/03/31/exchange-2010-and-netbios-domains-with-dotted-notations.aspx

    Yup, looks like an identified bug in Exchange 2010 and it will not be fixed until Rollup 4.  I did install Rollup 3 (which was released April 9th) to see if that would help the situation but it didn’t.  I guess at this point it is a matter of waiting for Rollup 4 to be released…..Bugger!

    —**UPDATE**—

    Working with MS support I was informed that there is an unpublished KB article pertaining to this issue.  If you do have this problem you will need to contact MS Support and refer to KB 981033.  It is my understanding that there is a fix for Exchange 2010 RU 1 and Exchange 2010 RU 3,  I received the update for RU 3 and will be applying it to the server later today.  The size of the update was approx. 35megs. 

    I need to point out that when installing this update you will need to remove it prior to deploying RU 4, which will have the fix in the RU 4 release.

    Thanks MS Support for getting this guy out here!

    Update Rollup 2 for Exchange Server 2010

    March 5th, 2010 by

    The Microsoft Exchange Team has announced the release of Update Rollup 2 for Exchange Server 2010.  For the announcement go here: http://msexchangeteam.com/archive/2010/03/05/454155.aspx

    Some key fixes are: 

  • KB 977633 This fixes IMAP4 clients ability to log on to their mailboxes if the mailboxes are located on Exchange 2003 backend servers and if the clients are connecting via Exchange 2010 CAS servers.
  • KB 979480 IMAPid was not working correctly after moving a lot of users from one Exchange 2010 server to another*. IMAP4 users complained about the inbox not being updated any more. Old messages were still visible, but messages which were received after the mailbox move were not visible. The problem affected different IMAP Clients. The problem did not affect MAPI clients and OWA. Now it is fixed up. *(Specifically this occurred in the situation with same DAG, now local storage instead of iSCSI storage, all servers are Exchange 2010 with Update Rollup 1 installed on Windows Server 2008 R2).
  • KB 979431 When user migrated from Exchange Server 2003 to Exchange Server 2010, and that user connected via POP3, the POP3 service crashed. This was fixed up so it will not crash.
  • KB 979563 Push Notifications didn’t work because Exchange Server 2010 was not sending SOAPAction header in the notify callback. This caused Exchange to receive a HTTP 500 response from the notification client and the webservice failed. Push notifications should now properly send that SOAP header.
  • KB 980261 We fixed passive page patching when diagnostic tracing code was needed for forensic analysis that was generating a -1022 error case.
  • KB 980262 Source side log copier errors are more gracefully handled when the log has a bad block and the read fails.
  • KB 979566 Activesync proxy was failing for linked mailboxes in a CAS to CAS proxy scenario where the users token is serialized and sent in the request. When attempting to create the client security context from the SID, a AuthZException was thrown because we did not have access to the token information of the linked account, so now for this it no longer throws exceptions.
  • For more information on the Hotfix you can go to the page at http://support.microsoft.com/?kbid=979611.

    Enjoy!