Exchange 2013 Security Update MS13-061 Status Update


Late last night we became aware of an issue with MS13-061 security update for Exchange Server 2013. Specifically, after the installation of the security update, the Content Index for mailbox databases shows as Failed and the Microsoft Exchange Search Host Controller service is renamed.

For those that have already installed the MS13-061 security update for Exchange Server 2013, we already have KB 2879739 that provides the steps on how to resolve this issue. However, due to this issue and that it affects all Mailbox server installations, we have decided to pull the MS13-061 security update temporarily.

Note: This issue does not occur in Exchange 2010 or Exchange 2007. You can proceed with testing and deploying Exchange 2007 SP3 RU11, Exchange 2010 SP2 RU7, and Exchange 2010 SP3 RU2.

Recommendation

If you have already installed MS13-061 security update on your Exchange 2013 servers, we recommend following the steps in KB 2879739 to resolve the issue.

If you have not installed MS13-061 security update on your Exchange 2013 servers, we recommend not proceeding with the update at this time. To mitigate the security vulnerability, we recommend following the workaround steps identified in the Vulnerability Information – Oracle Outside in Contains Multiple Exploitable Vulnerabilities section in Microsoft Security Bulletin MS13-061.

Question/Answers

Q: What is the impact of this security vulnerability?

A: Please see the information contained within the MS13-061 Security Bulletin.

Q: I am about to upgrade from CU1 to CU2, will I be affected?

A: No, this issue does not occur when upgrading to a cumulative update. This issue only occurs when patching a .msi installation via a .msp file.

Q: Why does this issue occur with installing a .msp file?

A: During the Exchange 2013 installation (.msi installation), the service is created, the Data Folder Location registry key is created and during a post configuration step, the registry key is populated with data and the service name is rebranded. During the .msp installation, these settings are reverted back to their original installation values prior to the post-configuration step.

Q: If I follow the steps identified in the workaround, will I have issues in the future?

A: Following the steps identified in KB 2879739 will resolve the issue and not cause any future problems.

Q: What happens if I uninstall the security update?

A: You will need to follow the steps identified in KB 2879739, otherwise your search infrastructure will be broken.

Q: Why didn’t you recall the update rollups for Exchange 2010 and Exchange 2007?

A: Both Exchange 2010 and Exchange 2007 utilize a different indexing architecture and, as a result, are not impacted.

Q: How was this issue not detected in Exchange Online if Exchange Online is always receiving fixes before on-premises customers?

A: Exchange Online does not deploy .msp patches into the environment; instead, Exchange Online deploys new full builds of the product (cumulative updates, if you will) on a regular release cadence. As a result, Exchange Online was not impacted by this issue.

Q: How was this issue not detected in your on-premises deployments?

A: Unfortunately, this security update did not get deployed into our dogfood environment prior to release.

Q: You have told us time and time again that you were going to improve your testing procedures, and yet each time you have to tell us that you missed something. When will it end?

A: We will work very hard to regain your trust and confidence. With that said, we have recently made the decision to delay the release of Exchange 2013 RTM CU3 by several weeks to ensure that we have enough run time testing within our dogfood environment. Also, we will ensure that all patches are deployed in our dogfood environment prior to release going forward.

We will continue to make improvements in our release cadence and testing methodologies over time to ferret out these issues. These changes may mean that our once a quarter release cadence for Exchange 2013 may change.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Comments (60)
  1. soder says:

    If I may start trolling: not impressed at all..

  2. Robert says:

    Saved again by not installing patches right away…

  3. Bob Hyatt says:

    Here we go again & again & again.

    QA guys at Microsoft are sleeping in the Cloud.

    Come on guys focus on giving your Exchange On-Premises customers good patches.

  4. JohnK says:

    @Bob On-Prem Customers = 2nd Class Citizens

  5. Brian says:

    I can understand producing updates can be complex but you introduced these measures to improve quality, you're not following them and you're letting us down! It's really disappointing, and leaves us wondering what real mileage there is left in MS Exchange On-Premises as you don't really seem to want us as customers. Obviously you want us to move to your cloud, but we don't want to do that!

  6. zumarek says:

    Just to clarify ? is Office 365 vulnerable to this exploit or was it patched ?

  7. Disappointed :( says:

    I'm seriously losing faith in your ability to deliver a stable ready-for-production product.  There are no excuses anymore for this kind of quality.

    I am embarrassed for you.

  8. Rug says:

    If we're using FOPE/EOP, is it protecting us against this threat?

  9. beejayvee says:

    Q: How was this issue not detected in your on-premises deployments?

    A: Unfortunately, this security update did not get deployed into our dogfood environment prior to release.

    Blah, blah, blah………blah, blah.

  10. Gary says:

    It's almost like On Premise customers of Microsoft's products are becoming the equivalent of food tasters for the King.

  11. Frank says:

    And what about this statement from Brian in the comments section of the CU2 security update/RU2 update blog post:

    Steve Mossberg 13 Aug 2013 11:45 AM #

    Brian, are these CU's/RU's getting tested? It appears that new bugs are created with each new fix. We are almost better off not apply the fixes. Any comments?

    Brian Day [MSFT] 13 Aug 2013 11:49 AM #

    @Steve, no we blindly release code and let you test it for us. ;) j/k I will defer to the last few Q&A bullets in Ross' previous article here for commentary on testing. Short answer is, absolutely we do. blogs.technet.com/…/e2013-rtm-cu2-issue-public-folder-permissions-loss-after-pf-mailbox-move.aspx

    ——–

    This is in contradiction – to say the least – to the acknowledgement in the Q&A above that the fix wasn't tested in MS's own environment….

  12. Glibglob says:

    Oh dear. I was toying with the idea of installing the update on all my servers last night but changed my mind. I'm glad I waited!

  13. pesospesos says:

    Appreciate the honesty, but as Frank points out this blatantly contradicts Brian's Day from Microsoft's comment from the other blog post.

  14. Tim says:

    After the NSA PRISM news companies in the US & outside of the US are NOT going to the Public Cloud.

    So let's all focus on the Exchange 2013 On-Premises with GOOD patches, come on Microsoft………….

  15. Again? says:

    Good hell. ANOTHER UPDATE gets pulled? How many is this now? 4v1, then it was 4v2, then it was 4v3. 5v1 then it was 5v2. CU2 was pulled. Now critical updates are being pulled? I'm sure I'm missing others. You're just now working to regain our trust and confidence? You've been constantly blundering updates for the past 6 months now.

  16. MS says:

    These things seems to happen very often, especially to Exchange and SharePoint product teams … it is really disheartening … we started patching only the most extremely critical holes … if Microsoft cannot properly test updates/upgrades with all of it's resources, how can it really be expected that we can test them enough before deploying?

  17. Susanne says:

    I stopped patching a year ago, after Ex2010 SP2 RU4 there were so many bugs … I haven't got the time and the infrastructure to test everything. our environment has to be stable. thats the most important thing!

  18. Hans says:

    Microsoft should STOP imitating Apple and it's products and should focus again on the business consumers!

    We want stable and reliable software solutions (like Exchange Server used to be between 2000 and 2009) and not pseudo cool and hip products which run like an old, beat up car.

  19. Brian Day [MSFT] says:

    @Frank, yup I certainly am owed a plate of crow to eat on that comment. It's as of Mr. Murphy himself came down and struck me. Feel free to swing by and harass me at MEC for it. I am both embarrassed and shocked to see what transpired here in this particular situation.

  20. zumarek says:

    Ross

    I suggest that you follow vendor recommendation and apply  this fix in your dogfood system as described in:

    technet.microsoft.com/…/MS13-061

    “For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software …”

    With one modification if I may … “You should test it on non-production system first”.

    It seems that there is a fundamental flaw in the process as this “tiny” patch in no way should result in such a mess. Also, I understand that CU approach is under review. Yes pushing on prem customers to update every 12 weeks is not such a great idea after all.

    In my opinion for all on prem, unless you have no choice stay with what works, or go to Office365 and relax.

  21. SN says:

    I'd like to know all the names of the managers you plan to fire that did not direct their staff to run this fix through your test environment.

  22. Ross says:

    Things just happened. Hope the Exchange 2007/2010 patch will be good enough….

  23. FoolMeOnce... says:

    Yeah, right.  MEC = the Microsoft Excuses Conference.

  24. zumarek says:

    Ross

    Yes they do … http://www.infoworld.com/…/microsoft-botches-six-windows-patches-in-latest-automatic-update-224988

    The Difference Between Confidence and Arrogance is …… ?

  25. Sharique Ahmed says:

    Sorry to say, but what are your engineers up to ? Ross you look like a Lion leading a pack of donkeys.  

  26. Sm says:

    I agree with most of the negative comments especially the one about on-premise customers.  We're still considered customers right?

  27. randy says:

    Thank you for being honest and we really do appreciate your team's hard work.

    But just want to say that over the years we've been conditioned, as Exchange admins, to sit back and wait a few days/weeks before installing RU's because there's a very good chance the RU will break something major.  Hopefully you guys will take the lessons learned from all the "RU v2" incidents and up your game.

  28. PissedOffAdmin says:

    Pretty sure they are currently spending 50% of their time in "lessons learned" meetings…

  29. Jone says:

    I'm also getting this: MSExchangeFastSearch event id 1010. No connection could be made because the target machine actively refused it 127.0.0.1:3803.  —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:3803

    Cant' activate passive databases any more….

  30. B. Barnes says:

    On one hand we need to always update to the latest CU or service pack in order to maintain our support with Microsoft. However, all of the recent patches break things. For example, the latest CU2 patch appears to have broken OWA redirects and password resets in addition to a whole host of other bugs we are finding. Pulling the previous patch due to PF issues and then less than a week later another show-stopping bug. It's madness. Simply madness. And now we find out that Microsoft doesn't even test the patches internally first. Not even critical ones. Get out of town.

    1.Is there a change planned to the upgrade cycle where we can have more time to test and iron out all these bugs? This forced N-1 upgrade support is just not sustainable with the amount of shoddy patches being released. We can't update our servers every quarter and watch things break.

    2. Since TechNet is going away, how can we continue to test Exchange without having to pay over 6000? The free and/or online labs don't include Exchange 2003 or 2007 and you can't download them anymore, which is most of what my customers are upgrading from. We also cannot test any complicated scenarios. We can't even test forest trusts and certificates.So, how does the Exchange team envision people deploying Exchange if we can't download and test the software adequately?

    Thank

  31. Brian Day [MSFT] says:

    @B. Barnes, you are not required to be on the N or N-1 CU to be in a supported Exchange 2013 configuration. We will support older CUs, but for example we may issue an individual security update for CUs older than that. The wording used in the original Exchange 2013 servicing model blog article could have been clearer in that regard.

  32. Brian Day [MSFT] says:

    I'm missing a 'not' in the above comment. It should have said "…but for example we may not issue an individual security update for CUs older than that."

  33. B. Barnes says:

    Brian,

    Thanks for responding. Let me say that your messages aren't coming through clear at all. I was told by a MS representative that only the latest (CU2) and the previous version (Cu1) were supported. If a customer was running RTM, then as soon as CU2 was released, that customer was required to upgrade. You are telling me something completely different. It's not just the blog that is confused or your own customers, it's also your own internal staff as well. So, what exactly is supported now and what isn't? Is there a proper link?

    I would also appreciate it if you could address my TechNet retirement concerns as well. What does the Exchange team plan on doing for their Exchange certified administrators in order to enable them to continue to support migration and other efforts? The new solutions proposed by the TechNet team are inadequate, do not include previous sw, or are too costly to maintain. Perhaps you could address our concerns in a follow up blog post?

    Thanks

  34. HeyAdmin says:

    I hope M$ provides free support to resolve fallout from batch security updates.

  35. Brian Day [MSFT] says:

    @B. Barnes, feel free to send any MS employee telling you that my way. My alias is brianday for them to find me. I am not familiar enough with the current TechNet situation and what we have available for labs so I'll withhold comment for now.

  36. itworkedinthelab says:

    Does this affect exchange 2003 on premises customers?

    (you never know that's why I'm asking:))

  37. Jangotamed says:

    too bad cause exchange is a great product seriously

    but its starting to "fail" like a good German car with lousy service

  38. Exchange2003 not impacted says:

    Per the KB/security bulletin, Exchange 2003 does not have the outsidein code and thus is not impacted

  39. So now I'm confused says:

    B. Barnes is right, only CU1 and CU2 (aka n-1 and n) are in support.  There's no patch for Exchange 2013 RTM for example.  If you are on RTM you must upgrade to at least CU1 in order to install this security update.  

  40. Brian Day [MSFT] says:

    @So now I'm confused, that falls in line exactly with the process I mention above. We may not issue security updates for more than N-1 back (which is RTM in this case), but the code is still _very_ much supported. If you were to call support for RTM they would certainly work with you and not force you to upgrade to CU1 to troubleshoot an issue. They may however suggest you upgrade if the issue you called in about is a known-fix in an already released CU. If however you felt a certain security update released for N or N-1 was something you need, then at that point you would need to upgrade to at least N-1. Being under 'supported' does not mean the same thing as a guarantee for patches to be released. We still support Exchange Server 2003 SP2, but there have been no new updates for it in a long time.

  41. B. Barnes says:

    Brain,

    So since security updates are only released for N and N-1 code, then by default we can’t run Exchange code older than that. We cannot present to our management that we have no ability to deal with security updates. Therefore in order to run Exchange in-house,
    we are now limited to the current version and one version back. We’re forced to upgrade everything at least twice a year if not sooner. This appears to be the only way to be in "best practice".

    I’m still very much confused as to what we need to do in order to be successful. It seems like we are being offered a catch-22. We either deal with no security updates or we are forced to update to buggy and unproven (remember, MS isn’t even testing this
    code now themselves) code base?

    If you are not familiar with the TechNet issue, please let me enlighten you. Over 9300 admins have signed this petition. You should read the comments as it will affect all of Microsoft’s Exchange administrators.

    http://www.change.org/…/continue-technet-or-create-an-affordable-alternative-to-msdn

    Thanks

  42. itworkedinthelab says:

    sometimes I ask myself

    who are these creatures:)

    it was a joke:)

    guess I shouldn't leave my day job eh

    ………………………………………………………….

    Exchange2003 not impacted  

    16 Aug 2013 1:10 PM

    #

    Per the KB/security bulletin, Exchange 2003 does not have the outsidein code and thus is not impacted

    ………………………………………………………..

  43. zumarek says:

    Support for earlier version of CUs and Exchange is there, just be prepared to update if your issue requires that you apply CU in order to solve it. As far as what Microsoft partners are saying … well this is another topic. They seem to be confused with fundamentals … Before you listen to any use your search engine …

    We seem to confuse functionality and security. You can have functional product that is not secure and I think this is what Brian is telling us here. Many customers already sacrificed security for functionality and stability. What good is secure system that is at risk every 3 months. This is why we have so many still running Exchange 2003, Office 2003 and Windows XP, or people stop applying patches, or use 3rd party product to secure Exchange. If you have LOB application that requires Exchange you are left with no choice really.

    Few years ago I remember the notion of slowing down development and focusing on security and quality … I cannot speak for all IT Pros, but let us focus on security and Microsoft can focus on quality of the product. If you published documentation of changes/updates/enhancements like IBM does for Domino Fix Packs many of the problems could be potentially avoided.

    Personally I don’t even understand why we complain … what other options we have?

  44. Jason Bailey says:

    @B. Barnes:

    I'm glad someone else is having issues with the OWA redirects in CU2 as I had a support ticket open with MS for nearly 3 weeks with that issue without it being resolved, in our case it affected the redirect to mailboxes on Office 365. In the end as I had students coming back on Campus I installed all new exchange servers with CU1, migrated all of the mailboxes to the CU1 servers and removed the CU2 servers.

    The guys asked me for a heap of logs off the upgrade servers despite the fact I did a brand new installation in a new forrest directly with CU2 and had exactly the same problem so it wasn't related to the upgrade.

    Fortunately the loss of Technet trials for testing isn't an issue for me as were an educational institution with MSDN as well but it was clearly poorly thought out.

    Jas :)

  45. ABCFED says:

    Had a lot of issues with the latest update. After installing CU2 on an RTM Exchange 2013 system:

    1. The POP service was sending out the wrong certificate. As crazy as that sounds, POP clients were getting the NetBIOS name of the cert rather than the certificate that was assigned the "P" services. Had to =$null the server certificate and edit the ehlo response of the pop service in order to assign the correct cert. This was working fine in RTM and broke in CU2.

    2. OWA redirects broke. I believe we now have to manually delete the web.config file and re-set the redirects. That seemed to fix it. Hopefully there is a better answer.

    3. The move-mailbox process introduced a new bug. You have to edit the conf file for the migration parameters to avoid processing delays. Someone set the default to timeout 480 times (each timeout taking 2-3 minutes). You have to set this value to 1.

    4. During the move process we had to manually verify the log status of each move due to Exchange 2013 not cleaning up the source Exchange 2007 mailbox correctly. Fortunately the log showed that the AD switched correct, so we just cleared the move request for those users manually.

    5. Once the update installed, we never could get Exchange 2013 to ever send back to Exchange 2007. We ended up doing a cutover migration of the mailboxes and the mX at the same time. Never did resolve that issue.

    6. The public folder replication, of course, had problems. The PF migration always seems to have problems. We ended up just manually exporting and re-importing via the Outlook client.

    7. Delegate automatic mailbox assignment appears to have stopped working. The clients do not automatically assign the mailboxes in the Outlook pane after ~60 minutes. Manually adding the mailbox appears to work.

    8. Troubleshooting was made very difficult in some cases due to Microsoft now integrating ipv6 into their client, transport, and storage layers. Breaking the standard TCP/IP and/or ISO models really makes troubleshooting IP/NS issues much, much tougher.

    There were other various minor issues.

    Some questions:

    a. The users hate the look and feel of the new OWA. They complain about the whiteness, non-3d look, and general lack of customizability. Adding a little row of "theme" across the top is not sufficient. Is there additional themes and/or color choices planned? Is that coming in SP1 or before?

    b. The ECP appears pretty stark and lacks a number of critical features that must be done via PS. The admins really felt it was" a step backward" to go to Exchange 2013 from 2007. Their words. They also felt the ECP wasted half the space on the screen and was "way too white" as well as the OWA. Is the ECP going to be enhanced?

    c. Where did all the cool neat GUI tools that were in the old Toolbox go and where is the BPA now? Are they ever coming back to Exchange 2013?

    :)

    Best,

              – S….

  46. Jeff Guillet [MCM MVP Author Blogger] says:

    Please see my article about fixing OWA redirects.  http://www.expta.com/…/owa-2013-cu1-redirection-is-broken-for.html

  47. Evgeniy says:

    Guys, could you please take a look at social.technet.microsoft.com/…/exchange-2013-does-not-permit-sending-messages-to-addresses-with-substring ? It's not related to this article, but I'd appreciate a comment from a developer.

  48. Brian Day [MSFT] says:

    @Evgeniy, that does not appear to be a valid local portion of the SMTP address format. I'll respond more in your thread.

  49. This is Funny says:

    "In the Exchange world, this means that we deploy extremely early version of Exchange in production starting with a few mailboxes, hundreds of mailboxes, then working with MSIT to move thousands of mailboxes – and eventually deploying to the entire company."

    blogs.technet.com/…/crazy-about-dogfood-and-dogfooding-hybrid.aspx

    Whoops, looks like you don't do what you preach.

  50. Dogfood says:

    I would like a clear explanation of why Microsoft is now not testing software before releasing it to the public.

    This revelation is complete and utter bullshit and I think heads should roll.

  51. ABCFED says:

    Finally found out the solution to allowing Exchange 2007 to receive e-mail from Exchange 2013.

    social.technet.microsoft.com/…/cannot-send-mail-from-exchange-2013-to-exchange-2007

    Apparently there is yet another bug that requires you to create new receive connectors in order for the communication to work between 2013 and 2007. The default connectors won't work right now "out of the box".

  52. Brian Day [MSFT] says:

    @ABCFED, mind sharing the step you felt fixed it? I have had numerous labs with 2007/2013 in them and not had cross-version mail flow issues with the default connectors.

  53. ABCFED says:

    Brian, it appears that the default receive connectors were causing issue. Once you create new receive connectors and verify the IP space mail flows.

    Also, as a side note, just had an Exchange 2007Sp3RU11 update corrupt the EWS directory yesterday as well. Had to remove-webservicesvirtualdirectory ews, iisreset, and re-add to fix the problem. Was working with no issues prior to update. Not real happy with the latest round of patches.

    I would like to echo some of the other comments here about TechNet retiring. This is such a critical service for all Exchange technicians. How can we, the Exchange community MCSEs, and others still obtain the Exchange 2003, 2007, 2010, and 2013 bits in order to support and migrate the current customer base if we can't even access anything older than 2013? I cannot move a customer from Exchange 2007 to the Office 365 cloud if I cannot test or access the Exchange 2007 software anymore to verify. I can't even train someone to do it. What is the solution that the Exchange group would recommend for people in my position to continue to provide software support for our customers?

  54. Brian Day [MSFT] says:

    @ACBCFED, what was wrong with the default receive connector or what did you make different about the new receive connector? I have yet to see any issues in this area and would like to attempt a repro.

  55. ABCFED says:

    Brian,

    Had an Exchange 2007SP3RU10 server. 120 users with 180 mailboxes. Installed Exchange 2013CU2 in the organization. After migrating a test mailbox to the new Exchange 2013 server we noticed that the test user could not send back to the Exchange 2007 server. The Exchange user could send and receive from the Internet (via the send connector on the Exchange 2013 server and the Internet receive connector on the Exchange 2007). The Exchange user could not send e-mail to any user on the Exchange 2007 system.

    Being off-hours and a scheduled window, we switched the mail-flow at the firewall NAT to route incoming to the new Exchange 2013 server. We determined that if a mailbox was on the Exchange 2013 system, mail flowed fine. We determined at that point to switch the mail flow during the user migration window in order to resolve.

    After the migration we powered down the Exchange 2007 server to verify. I spun the server back up and created a test mailbox on the 2007 side. I could not send an e-mail from a 2013 user back to the 2007 mailbox…but the 2007 test mailbox could send fine including to and from the Internet. I then created new receive connectors on both the 2007 server as well as the 2013 server. I allowed anonymous and added the exchange server as the source. Wham. Mail started flowing and the queue emptied.

    At that point I decided to bag it…and we finalized the uninstallation of the 2007 server and just called it quits. That's really all there was. Rebooting the servers didn't help. I'm almost curious if it had something to do with IPv4 or IPv6 issues…but again, it's impossible to troubleshoot IP-related problems now with the new Exchange development model that throws out traditional TCP/IP.

    If you read the technet forums link I sent you'll see there are a few others who had pretty much the same symptoms I had. We also had some very strange behavior with the certificates as well. Pop was assigned to a "mail.company.com" SAN certificate, yet the Pop clients were getting the NetBios server certificate instead and security was failing. The timeout in the config file was really problematic. What was scheduled for a 4 hour move window (since we'd used the suspendwhenready option) turned into a 24+ hour problem very quickly.

  56. TiredOfThis says:

    The latest in a long-line of Exchange screw ups.  No wonder O365 is doing so well… Oh, maybe that's the point.

  57. Brian Day [MSFT] says:

    @ABCFED, thanks for the detail. That situation certainly isn't "proper" as Exchange expects to be able to perform Exchange Auth between the servers and the fact that you had to enable anonymous tells me something was breaking down there which we could probably diagnose with SMTP logging. Did anyone do something like untick IPv6 from the NIC on either server? The reason I pushed for details (I hope you don't mind) is many times when the 'bug' flag is raised by customers we tend to find it is a misconfiguration in the OS or Exchange. In no way am I saying we don't bugs (hell, this thread is proof enough), but something as core to the product as mail flow between versions is something the whole world would be blowing up about if it didn't work out of the box. :) -b

  58. ABCFED says:

    Everything I am setting up I always make sure that both IPv4 and IPv6 are enabled. I understand those are now both required as the Windows team does not support turning them off even if ipv6 isn't used. If you turn off ipv6 things like direct access, DAG, and others will break. I understand that is Microsofts official recommendation to leave ipv6 on.

    That said, it makes zero sense to have ipv6 enabled. Putting IPv6 in the client, business, and data layers was absolutely the WRONG way to go. You should have stuck with the tried and true OSI and/or TCPIP models taht separated the IP stack from the session, presentation, and app layers. If you'd stuck to the standard models for application design I could definitively understand and verify if IPv6 was causing an issue. Unfortunately the way you've now coded the new Exchange applications, it makes it impossible to really track down IP issues. I'm not here to berate you for the architecture, just saying – it's a pain now to troubleshoot IP issues and it wasn't before in Exchange. I think a number of issues have been caused due to this new architecture.

    That was just a guess though as to what the issue "may" be…but back to the real issue, yes, with a brand new fresh Exchange 2013 install it would not send back to Exchange 2007 until we added/modified the default connectors. I'm just throwing out guesses as to what was the actual problem.

    My bigger concern was the certificate that wasn't correctly handed out to the client even when specifically assigned to the service and the massively delayed migration process due to the wrong config data being present in the latest update. Those really caused a LOT of pain and the customer was very, very unhappy with the process.

  59. ABCFED says:

    Brian,

    I am referring to this:

    blogs.technet.com/…/exchange-2013-server-role-architecture.aspx

    Which IMO was a mistake. The Exchange team should NEVER have broken the standard OSI model. Causes lots of issues that are difficult to track down using the standard toolsets. Again, my opinion, but I would love the team to go back to where things were in 2010, which worked phenomenally great and were simple to troubleshoot. Of course…I would also love to get the winning lottery ticket too…

    lol

  60. JamesNT says:

    I have to say there are times, you know, late at night, when I lay awake thinking of my little girl and the upcoming student loans she's going to accumulate and part of my mind, you know, the conspiracy part that I rarely listen to and consider to be for entertainment purposes only, begins thinking things like maybe all these horrible bugs in Exchange 2013, and that lack of quality since Exchange 2010, isn't some scheme to get our bosses so fed up that they move our Exchange servers to the cloud and fire us all.

Comments are closed.