Next week I'll be at the Microsoft Exchange Conference 2014!!!
24 March 14 09:17 AM | dmstork | 1 Comments   

The Microsoft Exchange Conference 2014 will start in a week! As with the previous version I’ll be there too! For those attending, this is my MEC2014 profile (login required).

I’ll arriving Saturday late evening and I’ll leave the next Saturday in the afternoon. Unfortunatly no solo sessions, but I will certanly be there for The UC Architects Live session (code: ARC.IN.306 currently planned on wednesday afternoon)! Between the official event parties etc., ENow will also sponsor a The UC Architects party!!! Registration is required and can be done here: http://schedulemymaintenance.com/. To increase your chances to attend, listen to The UC Architects podcast episode 35 and check the promo code mentioned in it. You’ll certainly see me at this social event and a lot others.

 

For those who are interested, but do not attend; be sure to check my Twitter account @dmstork as I will undoubtedly be tweeting a lot of information. Expect important, less well known, interesting and breaking shiny new facts! If you have a question, feel free to tweet me and I'll see if I can answer your question myself or ask the speaker.

For those who don’t want a barrage of Exchange related tweets, it’s probably best to block/filter. Official event hashtags is #iammec, but expect a lot of #MSExchange as well. I’ll probably will blog about the event as well, but probably afterwards and not during.

I hope to see you there! 

 

 

Filed under: , ,
Updated - Exchange 2013 DAG, Windows Server 2012 R2 and VMware vSphere? Check support!
21 March 14 11:28 PM | dmstork | 1 Comments   

UPDATED 28/3/2024: See update below article.

A little heads up. While working on an extensive design including Exchange Server 2013 with Service Pack 1 installed on Windows Server 2012 R2, my eye caught a comment in the Facebook group Exchange Server 2013 (Facebook login required).

VMwares vSphere 5.1 and higher are shown to be validated by Microsofts Server Virtualization Validation Program (SVVP) to run Windows Server 2012 R2 VM’s. The hypervisor needs to be validated also as a requirement for virtualizing Exchange Server 2013. So far so good.

But you’re not there yet, the Microsoft Clustering on VMware vSphere: Guidelines for supported configurations (1037959) from VMware has a small footnote for this specific combination of Exchange and Windows OS. It’s only supported from vSphere 5.5. This is something that is easily missed (yeah, I would've missed it too if it weren’t for my procrastination on Facebook Smile). See the screenshot below with highlighting the specific sections (Click to enlarge image).

Click to enlarge image

I’ve discussed this with an VMware vExpert and although he didn’t know any specifics, it might have to do with some improvements for low-latency applications specific for vSphere 5.5. New features in 5.5 might also explain why for Windows Server 2012 it is stated that (among others) a DAG does not require explicit support statements from VMware.

Luckily we are still in the designing phase, so we can and will take this into consideration (either upgrade vSphere or use Windows 2012 R1). Even if it would work, I wouldn’t want to take the risk ending up in an unsupported situation (from VMware). Especially considering that when you implement a DAG, high availability of Exchange servers is something that is on your mind.

This is a good reminder to always thoroughly check support from all vendors before implementing the newest builds and versions.

UPDATED 28/03/2014: We submitted a VMware support ticket with this issue. Their answer clarifies the statements made in the KB: The combination 2013 DAG on Windows Server 2012 R2 hasn't been tested by VMware on other than vSphere 5.5, but it certainly doesn't mean that other combinations won't work. Either way, their support also stated that an explicit support statement isn't required from VMware when we decide to use vSphere 5.1 in this situation instead. That is in line with the support statements in the KB article for Windows Server 2012 RTM and it makes me feel more comfortable to go forward (without vSphere 5.5). But don't believe me at my word; I would advise to submit a VMware support ticket if you also want an explicit clarification directly from VMware.

Be careful with Outlook customizations! Use AutoDiscover!
20 March 14 09:24 AM | dmstork | 0 Comments   

During a migration from Exchange 2007 to 2013, we moved several mailboxes as pilot users. Coexistence was fully configured and on my test machine everything worked fine. However, the pilot users had trouble connecting with Exchange 2013 after their mailbox was successfully moved to Exchange 2013 servers. OWA and ActiveSync worked without any hitch.

The problem was that Outlook would update its server settings, even though (internal) AutoDiscover worked perfectly. Outlook seemed to retain its settings for Exchange 2007, which shouldn’t be the case. Due to architectural improvements in Exchange 2013, Outlook server setting isn’t a servername or CAS array FQDN anymore but a mailbox unique GUID combined with a @ + UPN suffix. Obviously this is not a server that Outlook can connect to, but as Exchange 2013 now always uses Outlook Anywhere externally and internally it that isn’t an issue. However, you can’t easily change those server settings as you would have to determine the specific GUID which can be a hassle for a servicedesk. So, Outlook really requires AutoDiscover to set server settings.

After investigation we determined that the Office 2010 deployment had customizations in place from the Administrative Installation Point, including hardcoded server settings towards the Exchange 2007 server environment. As it seems, these settings were so pervasive that a mailbox move to 2013 didn’t correctly update. Even when we forced (try, try again and when you don’t succeed use a hammer) and Outlook could connect to Exchange 2013, some features were still broken (OOF settings, for instance. Which relies on Exchange Web Services). A brand new profile seemed to mitigate all issues.

AutoDiscover was introduced with Exchange 2007 and was supported from Outlook 2007 and forward. Therefor it’s a mystery why the server settings were deliberately set in customizations. It might have been prudent during the Exchange 2003 days (which will end in about a month when mainstream support ends), but it’s unwise in combination with Exchange 2007, very unwise with Exchange 2010 (especially when you have site resiliency plans) and just plain st*pid with Exchange 2013. It’s not only there for initial setup, but also for any High Availability/failover plans you might have.

If you find the initial Outlook setup screens requiring user interaction by pressing Next and then Finish annoying, which even appear when connecting with a domain joined computer, you can let Outlook skip those by using the Office/Outlook GPO Administrative Templates specific for your version of Office. Enable the “Suppress recommended setting dialog” in the GPO (source). More general info here (specific for Office 2010).

TL;DR: don’t customize/script Outlook to connect to a predefined Exchange server. Be smart, let it use AutoDiscover.

Thanks to coworker SanderV for his investigation!

The UC Architects Episode 35: Service Packed! is available now!
18 March 14 08:22 AM | dmstork | 0 Comments   

A few days ago episode 35 of The UC Architects podcast went live! Service Packed!

With Steve Goodman hosting, joined by John Cook, Michael Van Hybrid, Michel de Rooij, Serkan Varoglu, Ståle Hansen and yours truly. Our editor was the legendary Andrew Price. In this episode we talk (a lot) about Exchange Server 2013 Service Pack 1, a quick review of the new features and the detected Transport bug and how we feel about that one. If you have plans to upgrade, be sure to check this part out!

Personally I’m happy with the new features and fixes of SP1 (even SSL Offloading, although Steve made some very good counterpoints), but the transport bug is kind of a downer although I wonder how many organizations would be impacted. Luckily Microsoft delivered a fix quickly, be sure to install it right after SP1. No re-issue of SP1 will be made, a permanent fix will be present in CU5.

We also talk about other Exchange updates, Office Web App 2013 Service Pack 1. Some important new scripts, Modern Public Folders and it’s limits. And a lot about authentication via ADFS and Multi Factor Authentication options in SP1 and in combination with Windows Azure. There is also some Lync news about several new tools. One topic is the ability to assign static IP addresses to Azure VMs, which led me to question whether it was the first step in supporting the new Exchange 2013 Edge role in Azure. It was part of a more general line of thought, some application would surely benefit from static IPs. This feature could be the step to officially support those applications within Azure, making it more mature. Because around the same time Exchange 2013 SP1 was released with the re-introduced Edge role, which is probably why my mind associated them both together.

And for those who are going to the upcoming Microsoft Exchange Conference in a few weeks, not only can you enjoy a live recording of an episode but if you wish to attend our UC Architects party sponsored by ENow, listen to the podcast carefully. You have to register @ http://schedulemymaintenance.com/ and in this podcast there is a mention of a promo code which increases your chances of admittance very much. Attendance is limited, stop reading my post and listen to this episode!

You can download the episode here, on the same page links relevant to this episodes topics are listed.

Exchange 2013 SP1 is out! And now?
27 February 14 12:22 AM | dmstork | 0 Comments   

Fireworks are seen over the Olympic Cauldron during the opening ceremony of the 2014 Winter Olympics in Sochi, Russia, Friday, Feb. 7, 2014. (AP Photo/Julio Cortez)Yesterday the Exchange Team finally released Exchange 2013 Service Pack 1 (SP1). And even as promised within early 2014! Nothing like a major release to get those blog writing blocks lifted Smile.  
Download SP1 here and see their blog here. Be sure to check out the release notes and the What’s New page.

So, what now? Hopefully many of you have installed previous Cumulative Updates (CU). But even if you haven’t (although I hope you’re not still stuck with CU1 or Zeus forbid RTM), you could right away install SP1 on top of your Exchange 2013 servers without installing previous intermediate cumulative updates (the name really is a clear hint isn’t it?). And although this update is called Service Pack 1, it’s technically Cumulative Update 4.

Features

Can we expect some new features? Sure! Let’s take a closer look to some of the features:

  • Windows Server 2012 R2 Support
    Now we can install Exchange 2013 SP1 directly on Windows Server 2012 R2. Not only that, it is now also supported to have 2012R2 domain controllers and a 2012R2 Forest Functional level. But remember: in-place upgrade from 2012 RTM to 2012 R2 when Exchange is installed is not supported (way way back with Exchange 2000 and 2003 was the last time that was possible). If you want 2013 SP1 on 2012R2 you need to re-install it. When you do that, also remember that Exchange servers in a DAG (Database Availability Group) should be of the same Windows OS (even if Exchange 2013 can support different builds within a DAG).
  • Edge Transport Servers
    Back again! This is not something I was very eager for, I haven’t installed much Edge transport servers with 2007 and 2010. But if you had one of those, now you can upgrade it so all Exchange servers can be a 2013 build.
  • Junk Email Reporting in OWA
    OWA (Outlook Web App) users can now report junk mail or false positives in OWA and the Microsoft Spam Analysis Team will analyze and take action accordingly. You will only benefit from this if you use Exchange Online Protection with your on-premises Exchange 2013 SP1 servers. I do wonder whether this information is also used by SafeList aggregation.
  • S/MIME for Message Signing and Encryption
    Never had the pleasure of implementing this security feature, but now the world is becoming more conscience about prying eyes I think it is a welcome addition. However, I think that Office 365 Message Encryption is more admin and user friendly (sender and receiver) but not all organizations can implement that (due legal restrictions etc.). Still only for Internet Explorer though…
  • Data loss prevention (DLP) improvements
    There are several improvements, most visible is the inclusion of Policy Tips in OWA and OWA for Devices which was a important downside IMHO. Document Fingerprinting is also an interesting addition.
  • AD FS claims-based authentication with OWA and EAC
    Now multi-factor authentication solutions for OWA and EAC (Exchange Admin Center) are possible due to the integration with Active Directory Federated Services (AD FS). However, this is only possible with Exchange 2013 SP1 servers, no co-existence is possible even with Exchange 2013 RTM.
  • SSL Offloading in Exchange 2013
    Finally official support for SSL offloading on all virtual directories. Especially those with Load Balancers with encryption accelerators will be happy, although if you use Content Switching in your load balancer (see my or Michael van Horenbeecks excellent post) it is also a very welcome addition! Unfortunately, configuration  is not possible via EAC or EMS (Exchange Management Shell). You need to use appcmd, except for Outlook Anywhere (Set-OutlookAnywhere) and Mailbox Replication Proxy (MRSProxy, for cross-forest mailbox moves. It has no offloading, you need to use SSL Bridging).
  • DAG without an administrative access point, Dynamic Quorum/Witness
    Tired of creating CNO’s by hand? Do you also forget to provide a static IP to you DAG? Well, that’s over now with Exchange 2013 SP1 on Window Server 2012R2. There are also some other improvements due to enhancements made in 2012R2. If you have a DAG with 2013, be sure to check out Scott Schnoll’s excellent post about the changes.
  • MAPI over HTTP
    A new communication protocol designed for this new (mobile) age. Even though Outlook Anywhere has got us this far, it’s an old protocol designed to work around downsides of the RPC protocol. It’s not enabled per default and for now only Outlook 2013 Service Pack 1 supports it. Check out Tony Redmond’s very clear and informative post about this new change and why you might want to enable it. I hope that Outlook 2013 RT on my Surface RT will support it Smile
  • Command Logging
    Not to be confused with Audit Logging. In Exchange 2010 you had a very educational and helpful (documentation) feature in the EMC, a PowerShell preview in which you could see, learn and copy cmdlets and one-liners. Unfortunately with the introduction with the web based EAC, that feature was gone. Although it’s not a preview, this Command Logging is still a welcome addition. See a post about it from Jaap Wesselius and Jetze Mellema (dutch).

Seeing this list of new features, it’s easy to forget there are also bug fixes. See a list here. I won’t go into them, but I have encountered some issues that are now resolved. Pfffeeuw Smile 

Installing

You might be very eager to install it right away, but I would take the path of caution. It’s still possible some nasty bugs are present in SP1, even though the Exchange Team has undoubtedly done is best to prevent those. But it has happened. So, I tend to wait for about two weeks and keep watching the blogosphere. When possible I also use that time to test SP1 in a lab environment, preferable as close as production environment as possible.

So, ready to install? What do you need to know? Basically it’s the same as with every 2013 CU. As always, check out the Release Notes there is helpful information present. I’ll highlight some of the most important gotcha’s below.

With this update, an Active Directory Schema Update is required. Plan this accordingly, especially if you have separate responsibilities.

Unfortunately the web.config files are still overwritten (insert sigh). So if you have customized them, which is the case when you have Lync IM integration in OWA, you need to re-apply those changes after updating Exchange. Do NOT reuse the previous configuration file, as with each update there are also crucial additions which otherwise would be lost. Edit the new configuration file.

Don’t forget to update (non US) UM Language files if you are using UM. You’ll probably triggered while trying to install SP1 as it prompts to remove them to continue. But still better to be prepared. Download the necessary Exchange 2013 SP1 Language UM files here.

Please note that mail flow can be “broken” after SP1 installation. You can restart the Microsoft Exchange Frontend Transport service, but I feel more confortable to restart the server after a CU or in this case SP1 installation. For more information about this issue see the posts from Paul Cunningham and Michel de Rooij.

When you are finished with the Exchange bit, don’t forget to update Office 2013 to SP1 (for MAPI over HTTP) and Office Web Apps Server 2013 with it’s SP1 if (when) you use it with the Exchange 2013 OWA Web Preview. The same goes for SharePoint Server 2013 which also saw it’s SP1 released, although I haven’t seen any changes regarding Site Mailboxes. Be sure to check this blog post of the Microsoft Office Sustained Engineering Team with all the Office updates and links.

Related

In a related note; Microsoft also released Exchange 2007SP3 RU13 and 2010SP3 RU5. For 2007SP3RU13 it’s a minor fix mentioned in KB2917522 (Edge 2007 publishing issue with Exchange 2010). The list for 2010SP3RU5 is a bit longer as listed in KB2917508.

Download links

Download Exchange 2013 Service Pack 1 (SP1)
Download Exchange 2013 Service Pack 1 (SP1) UM Language Packs
Download the Microsoft Office 2013 SP1 32-bit package
Download the Microsoft Office 2013 SP1 64-bit package

Download SharePoint Server 2013 Service Pack 1 (SP1)
Download Office Web Apps Server 2013 Service Pack 1

Download Exchange 2007SP3RU13
Download Exchange 2010SP3RU5

From open source groupware solution Zarafa to Exchange: Part 1, A New Beginning
24 January 14 12:01 AM | dmstork | 1 Comments   

This blog series will describe my experiences and lessons learned from migrating the Zarafa Groupware solution to Microsoft Exchange, specifically Exchange Server 2013. I've done this twice now and although some things are quite obvious, there are some gotchas and it might be a daunting endeavor. A normal transition from Exchange to Exchange already requires good planning, but it is even more important when migrating from a third party solution that isn't supported by any available migration tool like Quest. I hope that with sharing my experiences, others will have a more smooth migration and happy users. Even if you don't use Zarafa, most information will still be relevant when migrating from other (somewhat obscure) groupware systems or even from Exchange.

This part 1 post will give an overview of relevant topics in the upcoming posts.

Goal

The goal of the migration is to migrate existing mail from Zarafa to Exchange, in such a way that users will have the most smooth transition possible. Having said that, there will be changes in how users have to use Outlook. There will certainly be some downtime, there will probably be some (meta-) data loss and users will certainly have to reapply some of their settings, after they have been migrated. As an admin, it's important to acknowledge these things and prepare yourself and the organization for these changes. This will be discussed more extensively in a next part of this series.

Zarafa

But first, a little introduction of Zarafa Groupware. It's a Microsoft Exchange Server alternative; an open source community software suite that mimics Microsoft Exchange. It runs on top of Linux-based Operating Systems, but can be integrated with Microsoft Active Directory. Users can connect via its webmail, use ActiveSync via the open source solution Z-Push, and can use Outlook via a plugin provided by Zarafa. It's my understanding that it's relatively popular in Europe, because some (government) organizations prefer or are required to use open source software unless closed source solutions are proven to be a better fit.

Zarafa is the core product, but it requires other open source solutions for mail flow. Organizations are free to use some of those supporting products, which makes it flexible. But it also means it's not one big application with everything in it, and it requires admins to be knowledgeable about Postfix, Procmail and other solutions. There are multiple areas and programs where settings are required, in order to make the whole solution work as required. Where as you can administer practically everything within Microsoft Exchange, this is not the case with Zarafa, even when it's integrated in Active Directory. You could compare it with Microsoft Exchange Server 5.5 in some regards.

Whether it's cheaper or not, is something that I have debated regularly, but for now that is beyond the scope of this series. Zarafa can be compared with other like-minded solutions like Zimbra and OpenXchange, so as said some parts of this blog series could apply to those (and other) solutions.

I've migrated from Zarafa version 6.4 and 7.0 to Microsoft Exchange Server 2013 (first time to RTM and second time to CU3).

Exchange 2013

The target solution will be Microsoft Exchange Server 2013. While most actions described will be valid for Microsoft Exchange Server 2010 and perhaps even Microsoft Exchange Server 2007, the 2013 version certainly has it's own issues to take into account. Having said that, the focus will not be how to successfully implement Exchange Server 2013, unless there are issues specific to this migration scenario.

Overview

There are several aspects of this migration that are important enough to be blogged about. As time (and writing) goes by, they might (probably) change but as for now expect posts regarding these topics:

  • Inventory
    Know what you have, what's relevant and how it works, otherwise you can't know how to reach the end goal.
             
  • Active Directory
    How Zarafa integrates in Active Directory, which attributes are used by Zarafa and challenges.
            
  • SMTP Mail flow and objects     
    Things to take into account when functionality from Zarafa and it's MTA's (Mail Transfer Agents) are converted towards Exchange.For instance, Zarafa doesn't have mail-enabled Public Folders.
             
  • Client Access & Coexistence     
    Coexistence with different Exchange versions isn't always easy, but most scenario's are described by Microsoft or other bloggers. This isn’t the case with this scenario and I’ll show the impact and some possible choices.       
           
  • Migration and Export/Import of data
    How do you get user and public folder data from Zarafa towards Exchange and expected challenges. Expect the use of PST files.
             
  • Communication to users 
    Users will need instructions on how to survive the transition and to know what to expect. This is much, much more important than when you transition from Exchange to Exchange.
            
  • Planning & Concluding remarks
    Now you know what to do and how to do it, you can plan all necessary steps. Additional I probably have some concluding remarks, tips and tricks.
            

Concluding

Now you have a bit of an idea what to expect from this series.

If you already have some questions, remarks or even suggestions for additional topics, feel free to let me know via a comment or other means of communication.

Can you use ActiveSync to measure market shares?
18 December 13 12:08 AM | dmstork | 1 Comments   

Computerworld.com published an article this week called “iPhone, iPad dwarf mobile rivals in small- and mid-sized firms”. It stated:

Apple has won the hearts and minds of small- and mid-sized businesses, which have overwhelmingly adopted Cupertino's mobile devices over rivals powered by Android or Windows, an Exchange hosting vendor said last week.

Well, my interest was peaked. Mobile devices and Exchange, that is a combination for which I have a soft spot! Smile However reading the article and statements made, I found myself particular critical on their methods and conclusions made from the data. I decide to share those views with you, as some of you might use the same techniques in order to report device usage for BYOD policies for instance. It might provide some useful insight in the subject.

The original article used information supplied by Intermedia, an Exchange (2010) Hoster among other services, as a source (unfortunately I couldn’t find the information on their site). They state that most of their customers use mobile Apple devices (76%), with Android as a second (~18%, when added the shares from Samsung and Motorola) and Windows Phones and tablets as 1%, same as Blackberry (not stated whether this is exclusively BB OS10, as previous versions didn't provide ActiveSync). It is not stated what the remaining 4% is. Note that they have data from a longer period (36 months is mentioned), but these percentages only represent a year (from October 2012 till this years October). However, it certain that all devices are ActiveSync capable, because they tallied the activations. They’ve excluded mobile PC’s (notebooks) as they “access the hosted Exchange servers directly, without needing ActiveSync.”

So, is ActiveSync a correct way to count types of mobile devices? Well, I’ve done it myself and the protocol certainly can provide information about the device OS and even device model, but there are some issues with this approach. Not every user wants to connect their device via ActiveSync and there are alternative ways to connect to Exchange (Exchange Web Services, OWA, OWA Mini and less functional IMAP and POP). To be realistic, these alternatives aren’t widely known, certainly not as known as ActiveSync. Simply put, if a user has an mobile device it’s probably using ActiveSync to connect to company mail, it is still however an assumption. Using this method means that you can only say something definitive about active connected devices. Those that are not connected, but still bought and used possibly with other protocols than ActiveSync, are not counted.

Obviously one alternative to ActiveSync is Outlook (with direct MAPI and/or Outlook Anywhere). This is the reason why they excluded notebooks. But they are making statements about Microsoft Surface tablets:

“During the last three months of 2012 and the first ten of 2013, Intermedia counted just 1,700 Surface activations of all types, or less than half the number of iPads for October alone. Surface RT tablets, the lower-priced of the two lines, dominated, accounting for 62% of all Surface activations.”

The Surface Pro was able to run Outlook from the start and has a trail edition pre-installed. When used in a business context it’s possible it’s fully licensed. Although it’s possible, I don’t think a lot of users would use Outlook concurrently with ActiveSync (via the considerable less capable Mail app) on their Surface Pro.

In any case, determining Surface Pro and Pro 2 usage via ActiveSync will probably count less devices than actually present within a business. Since Windows 8.1 and the addition of Outlook for Surface RT/2 this will also be the case for those tablets. Unfortunately, there is no mention of this in the article. And on a side note, it might be very possible that users also preferred OWA than the Mail App before Outlook was available which could also undercount Surface (RT) usage.

Back to how they measured:

Intermedia measured mobile device preferences by tallying activations of ActiveSync…

Unfortunately there is no more information than this. I assume that they mean with activations new created ActiveSync partnerships. The question then is, is this a correct way to determine how popular certain devices are? I know that sometimes in order to troubleshoot, partnerships are removed and a new connection is made. Devices can break and be replaced. Some devices can hold multiple ActiveSync accounts, while some only one (I think iOS was one of the first to be able to have multiple accounts, and as ActiveSync doesn’t support Shared Mailbox/Calendars…). And not uncommon to businesses, devices are wiped and reused by other employees which make a new partnership to their own mailbox.

With this method they would count this device twice or perhaps more, potentially skewing the result towards a particular popular device range with a relative long usability or need-to-have factor (iOS perhaps?). There is no mention that they compensate for these instances, so I assume they do not. Personally, I would periodically check on the last sync time of partnerships of still active accounts and check what kind of device that partnership holds. That would eliminate most caveats I mentioned above. If I would be very thorough, I would even check for duplicate DeviceID’s within those active and previous partnerships.

Another point of discussion is that there is no regional information supplied. Intermedia supplies services to every country, but it’s very possible that they have more customers in one region than in the other and thus skewing the results towards the habits of one region. Unfortunately, they do not provide such information. It is however a fact that market shares of tablets, phone and other devices can vary greatly depending on the region for whatever reason as research by Kantar shows. Because of this I would argue that the statistics are only valid for the customers of Intermedia and probably cannot be applied to a global market.

Conclusion

Can they make definitive statements on device preference within small- and mid-sized business? Perhaps. They might not be too far from the truth and it is probably a relatively fair way to get an indication on device popularity. The keyword for me is indication; the information is mostly valid for Intermedia’s environment and the percentages only apply on connected devices that use ActiveSync.

It is my opinion that this article and it’s author (not necessarily Intermedia) are stretching the usability of the accumulated data too far and the article also lacks skepticism and criticism. I certainly wouldn’t extrapolate this research beyond these confinements without more information. I would argue that the statement quoted at the beginning might be true, but I would need more information to fully support it.

Unfortunately other sites (Surface stort in diep ravijn, Dutch) have copied the information and dropped even more nuances. Well, I hope I have restored some justice and order in the universe with this post. Winking smile If you have any remarks or questions, feel free to contact me or add a comment below.

Exchange Server 2013 Service Pack 1 news!
20 November 13 09:18 PM | dmstork | 0 Comments   

So, no Cumulative Update 3 (CU3) news but as promised by the Exchange Team they posted Exchange 2013 Service Pack 1 (SP1) news on the Exchange Team blog! It is coming early 2014, which I interpret as the first quarter of 2014. Because I now think CU3 will be released somewhere around early December (hint), I think SP1 could hit us around March. But I’ve been wrong before Winking smile

There are some features mentioned:

  • Windows Server 2012 R2 Support

This is not surprising, but nonetheless very welcome. I had hoped it would be in CU3 although CU4 would’ve been a more realistic timeframe, when regarding the quarterly update releases and the release date of Windows Server 2012 R2.

  • S/MIME support for OWA

Although I haven’t encountered this feature much and thus didn’t miss it much, I am glad it’s back.

  • Edge Transport Server Role

I find this a surprising move, as I would’ve expected that they would scrap it. Perhaps Exchange Online Protection (EOP, The Product Previously Known As FOPE) isn’t attractive enough, or they want to have a bite out of the mail appliances market. I am interested whether there will be new features introduced compared to Exchange 2010.

  • Fixes and Improvement

Well, not that surprising Smile. I do have to wonder what the real difference is between Cumulative Updates and Service Packs. I guess time will tell.

  

There are some things I kinda miss in this little summary, but it could be that they are already included in CU3.

Anyways: Go read the Exchange Team Blog post on Exchange Server 2013 Service Pack 1!

Filed under: ,
Can we expect Exchange 2013 CU3 and 2010 SP3 RU3 soon? Keep watching KB2891587 and KB2892464!
19 November 13 08:29 PM | dmstork | 1 Comments   

UPDATE 2013/11/20: It looks like the links currently don’t work anymore, possibly because they referenced a non-released update. That’s too bad, but even when the update is not available yet this kind of information is still quite valuable (something I pointed out in a comment on the Exchange Team Blog The Road Ahead post)

Just about an hour ago I saw a bunch of Knowledge base articles published for Exchange 2013 issues. All of them are fixed by Cumulative Update 3 which even has a link and description:

2892464 Description of Cumulative Update 3 for Exchange Server 2013

One even has a reference to Exchange 2010 SP3 Rollup Update 3:

2891587 Description of Update Rollup 3 for Exchange Server 2010 Service Pack 3

Both are currently not working, but this is a good indication that it it’s release is imminent. But below are the KB’s that mention issues for 2013 (and one for 2010):

2890650  Items in the Drafts folder are not stamped with the retention policy tag in an Exchange Server 2010 or 2013 environment

2888612 Retention policy does not work after you run a cmdlet in an Exchange Server 2013 environment

2889786 Sign-in format for Outlook Web App on mobile devices is not adjusted according to the Set-OwaVirtualDerictory cmdlet in an Exchange Server 2013 environment (typo is not mine Winking smile)

2895487 "Copy Search Results" option does not work in an Exchange server 2013 environment

2895678 "Nombre de usuario\dominio" is displayed unexpectedly on the Spanish version of the OWA and EAC logon pages in an Exchange Server 2013 environment

2902932 Internet Explorer 9 freezes when you use Outlook Web App in an Exchange Server 2013 environment

2882608 Exchange Server 2013 does not share the inproxy.dll file

2878160 "The Active Directory user wasn't found" error when you create or update an In-Place eDiscovery search in an Exchange Server 2013 environment

2871980 Child domains are not displayed for selection when you create a mailbox by using EAC in an Exchange Server 2013 environment

2888274 WebClientReadFormQueryString string and WebClientEditFormQueryString string return incorrect URLs in an Exchange Server 2013 environment

2886115 Retention policies are not applied to Exchange Server 2013 mailboxes when user accounts are on different domains

2865161 "Errors: Failed exporting item id: from source id" when you try to copy search results in an Exchange Server 2013 environment

2902934 Korean language localization issue in Exchange 2013 OWA user interface

2883203 Exchange Server 2013 restarts frequently after Cumulative Update 2 is installed

2902933 "Generate incident report" does not display the "Bcc" field in an Exchange Server 2013 environment

2902936 You cannot change SMTP addresses for distribution groups by using EAC in an Exchange Server 2013 environment

2902939 EMS connection error when you separately install an Exchange Server 2013 Mailbox server and a Client Access server

2902938 You cannot preview Office documents in shared folders by using Outlook Web App in an Exchange Server 2013 environment

2888315 Event 2112 or 2180 is logged when you try to back up a database in an Exchange Server 2013 environment

2895500 DBCS characters appear garbled when you run some PowerShell scripts in EMS in an Exchange Server 2013 environment

2902929 You cannot forward an external meeting request in an Exchange Server 2013 environment

Very interesting, I think one of the KB’s could fix an issue I’m currently experiencing although it’s occurring in Office 365.

Issues fixed by Exchange 2010 SP3 RU3 are:

2879320 Retention action setting is not updated in FAI items by running the Set-RetentionPolicyTag cmdlet in an Exchange Server 2010 environment

2840454 "The rules on this computer do not match the rules on Microsoft Exchange" error when you manage rules by using Outlook 2013 in an Exchange Server 2010 environment

2839533 RPC Client Access service freezes in an Exchange Server 2010 environment

2880290 RPC Client Access service crashes when you use Outlook in ANSI online mode in an Exchange Server 2010 environment

2882467 RPC Client Access service stops if Outlook is in online mode in an Exchange Server 2010 environment

2880153 RPC Client Access Service crashes if Outlook is in online mode in an Exchange Server 2010 environment

2879736 Office 365 users cannot retrieve an on-premises user’s free/busy data in an Exchange Server 2010-based hybrid deployment

2878175 Client Access server crashes when you use Outlook with a Riverbed WAN optimizer in an Exchange Server 2010 environment

2882677 BlackBerry device is not redirected in an Exchange Server 2010 environment

2874070 Public folders are exposed although the user does not have rights to see the parent folders in an Exchange Server 2010 SP3 environment

There are probably more issues fixed, but these were the articles I could find.

Windows 8.1 Enterprise upgrade: You can’t keep apps?
19 November 13 02:37 AM | dmstork | 0 Comments   

I was postponing my work laptop Windows 8 Enterprise upgrade to 8.1, because I assumed I would have to install every app over again. My Windows 8 Pro upgrade to 8.1 on my personal desktop didn’t go as smooth as I had hoped. I had to install every (desktop) application again, as I did not have the option to “Keep Windows settings, personal files, and applications” but only “Keep personal files only (data only)” or “Nothing”.

Now, I didn’t update my Windows 8 Pro (retail) from the Windows Store but rather from the earlier released RTM ISO from TechEd (while using my purchased retail key). This led me to suspect that the ISO “upgrade” was part of the problem. As Windows 8.1 Enterprise won’t have a Store update or installer file, I will have to do the same ISO installation on my Windows 8 Enterprise work laptop as I did with my desktop. That didn’t sit well with me…

These aren't the options I'm looking for...

Looking for explicit answers I examined the upgrade paths for Windows 8 which showed that Cross-language Windows 8 updates does not provide the option to keep apps. I surmised that a Dutch version was used with the initial installation and I was now trying to upgrade with an US English version. However, trying to upgrade using a Dutch ISO did not provide me with the coveted “Keep … Applications” option. A web search didn’t help me any further.

Then I remembered that before my Surface RT could get the Windows RT 8.1 Preview, I had to remove all non-US English language packs. And now I had a new hypothesis: installed language packs could prevent keeping my apps, thus I removed all but US English on my Windows 8 Enterprise laptop and rebooted (important!). After this I finally got the option to install with the option to keep applications, while starting the upgrade from an ISO file! I am now running Windows 8.1 Enterprise without reinstalling (most) of my applications. Woohoo!

There is probably a logic here, but I think that a lot of users would appreciate the installer (or even an explicit mention in documentation) telling you why an option is not available. Granted, most non-tech users won’t upgrade from 8.0 to 8.1 via ISO. But the effort on Microsoft's side would be minimal, it would’ve saved me some time and I would’ve upgraded more quickly to 8.1.

Exchange RBAC might be more granular than you think
11 November 13 10:10 PM | dmstork | 0 Comments   

Most Exchange admins probably know (or should know Winking smile)  the permission model since Exchange 2010 is Role Based Access Control, RBAC for short. With it, you can regulate quite granularly what admins and end-user are able to do, without the hassles of Access Control Lists (ACLs).

However, it recently became clear that it might be more granular than you think. You can allow only certain types of PowerShell Cmdlets, have only change rights on a certain Organizational Unit (OU)or types of users etc. etc.  But did you know you can also control access to certain parameters of Cmdlets instead of allowing or blocking a whole Cmdlet?

Consider the scenario that you want to give a certain servicedesk employee rights to edit mailboxes with Set-Mailbox, but for whatever reason you don’t want them to edit quota settings?

Here’s how you do it:

We start off by making a new ManagementRole based on the default created “Mail Recipients” role with the New-ManagementRole Cmdlet. You could make a brand new ManagementRole and add in all the required Cmdlets, but the default is close enough for this situation:

New-ManagementRole -Name "Mail Recipients No Quota" -Parent "Mail Recipients"

So, now we have a new ManagementRole, but we have to edit what it’s members are allowed to do with the Set-Mailbox Cmdlet. We want to remove any parameter related to quotas and we can do that with Set-ManagementRoleEntry and its -RemoveParameter option:

Set-ManagementRoleEntry -identity "Mail Recipients No Quota\Set-Mailbox" -Parameters IssueWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, UseDatabaseQuotaDefaults -RemoveParameter

Isn’t RBAC great? Smile

 

#Edit 2013.11.11: I’ve noticed (after writing and publishing this one) that I already wrote a post about customizing RBAC almost two years ago, in which I even used the same example Open-mouthed smile. The focus was a bit different, so it’s still a good additional read: Handing out only Send-as permissions with Exchange 2010 RBAC

I will be presenting at the NGN Exchange evening event on 25th November
08 November 13 02:27 PM | dmstork | 0 Comments   

NGN-logoOn the 25th of November the Dutch usergroup NGN (Netwerk Gebruikersgroep Nederland) will organize an Exchange themed evening event and I'm one of the speakers. I'm extra excited as it will be held at the OGD ICT Diensten head office in Delft, my employer!

My session will be about Exchange and mobile devices, focused on ActiveSync but also on Outlook Web App and the OWA App for iPad/iPhone. A very interesting and currently relevant topic, if I say so myself Smile. Other speakers will present a session about Office 365 and another about Exchange integration with Lync.

For more information and registration check this link (Dutch). A fee is required (addition NGN Membership is also required) and the event has limited seating.

[Dutch Translation:]

Op de 25e November organiseert de NGN (Netwerk Gebruikersgroep Nederland) een Exchange thema avond en ik ben één van de sprekers. Ik ben extra enthousiast over dit event aangezien het bij mijn werkgever OGD ICT Diensten word gehouden op het hoofdkantoor in Delft!

Mijn sessie heeft als onderwerp Exchange en mobile devices, met een focus op ActiveSync maar ook Outlook Web App en de OWA App for iPad/iPhone zullen behandeld worden. Een interessant en relevant onderwerp, als zeg ik het zelf Smile. Andere sprekers geven een sessie over Office 365 en een sessie over Exchange integratie met Lync.

Voor meer informatie en registratie zie deze link. Er wordt een vergoeding gevraagd (naast NGN lidmaatschap) en het event heeft een beperkt aantal plaatsen.

Blocking the Windows 8 Mail app in Exchange 2010 & 2013
18 October 13 01:37 AM | dmstork | 1 Comments   

I think I might start a new tradition: every time a major/important OS or update is released, I try find out how to block it from Exchange Smile.

Now, I know the Mail app has been around for some time now. If you recollect, I did some research on how Exchange ActiveSync (EAS) within the Mail app works in general and how it implements security settings in Windows 8. But especially since Windows 8.1 RT has been released yesterday with Outlook 2013 RT in it (woohoo!), there could be valid reasons admins want to prevent users configuring and using the Windows 8 Mail app. So, what are our options?

The process is basically the same as with my previous post Blocking iOS 7 in Exchange 2010 & 2013, although it will be a bit more tricky when there is a need to differentiate between “normal” Windows 8 and Windows RT. But let’s just see what we can see.

First I listed all mobile device partnerships with Get-MobileDevice (for Exchange 2013 or Get-ActiveSyncDevice for 2010) and look at important values. An example of one partnership is shown below, some irrelevant values have been stripped and I’ve highlighted interesting ones. The interesting ones are based on the possible values we can base our device access rules on (DeviceType, DeviceModel, DeviceOS and UserAgent).

FriendlyName            : GHORRT
DeviceId                : 7C35CB29F19565EDXCXDXXXXXDBXXBDX
DeviceOS                : WINDOWS
DeviceOSLanguage        : English
DeviceType              : WindowsMail
DeviceUserAgent         : WindowsMail/17.4.9600.16384
DeviceModel             : Microsoft Surface with Windows RT Surface_RT_1_IDP
FirstSyncTime           : 17-Oct-13 19:18:02
UserDisplayName         : dmstork
DeviceAccessState       : Allowed
DeviceAccessStateReason : Global
DeviceAccessControlRule :
ClientVersion           : 14.1
ClientType              : EAS

This is my Surface RT, in this instance already upgraded to Windows RT 8.1. Parameter DeviceOS has the value “WINDOWS”, unfortunately there is no difference between any versions of Windows 8. You could block all of Windows 8/RT if that is sufficient, but I wonder what would happen with Windows vNext (i.e. Windows 9). Other thought is whether a specific (non-Microsoft) app that uses ActiveSync will also be blocked (or quarantined). Something to consider.

The parameter DeviceType has the “WindowsMail”, which stand to reason that this is the Windows 8 Mail app. I did not see any variations.

Like iOS, it’s theoretically possible that certain updates of the Mail app can have issues. It seems if you wanted to block certain versions, the DeviceUserAgent parameter is the one to choose. Do note that I’ve seen at least 8 different version numbers, from “WindowsMail/16.4.4206.0722” to “WindowsMail/17.5.9600.20279

And last but not least, the DeviceModel parameter. With these values I would suspect you could differentiate between the Surface Pro and the Surface RT for instance. And indeed there are distinct values: “Microsoft Surface with Windows RT Surface_RT_1_IDP” for the Surface RT and “Microsoft Corporation Surface with Windows 8 Pro Surface_PRO_1” for the Surface Pro. I haven’t seen any variations, but the upcoming Surface 2 and Surface Pro 2 will probably/hopefully have different values.

If you want a nice overview with relevant values of all Windows 8/RT clients within your Exchange organization, use this cmdlet oneliner:

Get-MobileDevice|Where-Object {$_.DeviceUserAgent -like "Windows*"}|ft DeviceOS, DeviceType, DeviceUserAgent, DeviceModel -a

As said, you can block or quarantine these via the ABQ using the cmdlet New-ActiveSyncDeviceAccessRule (for Exchange 2010, 2013 and Office 365 via Remote PowerShell). This will also work when these particular parameter aren't present already. In the example below I quarantine all Surface RTs:

New-ActiveSyncDeviceAccessRule -QueryString “Microsoft Surface with Windows RT Surface_RT_1_IDP″ –Characteristic DeviceModel -AccessLevel Quarantine

This also works in Office 365/Exchange Online, if you were wondering.

Conclusion

Yes, you can block (or quarantine) the Windows 8 Mail app. However, you cannot distinguish between the different versions of Windows 8, RT included. You could differentiate between versions of the Mail app, but that is quite cumbersome due to the great variation of versions (and the new autopdating of apps in 8.1) and the version strings seem to be independent of Windows version. You could choose to block the Surface RT in order to force the use of Outlook 2013 RT, but that does not block other tablets with Windows RT (albeit they are becoming more rare). Basically, it’s all or nothing for the Mail app.

19 October 2013 Update: The Microsoft Exchange Team published a blog post yesterday about Windows 8.1 Mail app: Supporting Windows Mail 8.1 in your organization

Blog series on Windows 8.1
14 October 13 05:26 PM | dmstork | 1 Comments   

As it is almost October 18th , a quick plug for my Dirteam.com "co-blogger" Sander Berkouwers 10-part series on the upcoming Windows update: Is your organization ready for Windows 8.1?

Part 1, Overview
Part 2, The best hardware for the job
Part 3, Start Button and Boot to Desktop
Part 4, Automatic App Updates
Part 5, Managing SkyDrive
Part 6, Start Screen Layout Management
Part 7, Managing Start Screen Theming 
Part 8, Start Screen App Pinning  
Part 9, Disable help tips in The New Interface 
Part 10, Group Policy Caching
Part 11, Internet Explorer Enhanced Protected Mode

And as a bonus:
KnowledgeBase: Update adds support for Windows 8.1 and Windows Server 2012 R2 clients to Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 KMS hosts

 

Filed under:
Failed Exchange Server 2013 CU2 & CU3 install due to security update 2874216 (updated again)
25 September 13 02:17 PM | dmstork | 1 Comments   

Today a customer asked for my help because an installation of Exchange Server 2013 Cumulative Update 2  (v2) had failed; Their Exchange environment didn’t work anymore and they were stuck.

During the installation from Cumulative Update 1 (CU1) to Cumulative Update 2 (CU2), they encountered the following error:

Error:
Unable to remove product with code 4934d1ea-be46-48b1-8847-f1af20e892c1. Fatal error during installation. Error code is 1603. Last error reported by the MSI package is 'Unable to install because a previous Interim Update for Exchange Server 2013 Cumulative Update 1 has been installed.  Please use Add/Remove Programs to uninstall the Interim Update before running this setup again.'.
    

As specified in the release notes (although I can’t find this remark anywhere anymore), every interim update has to uninstalled before installing a Cumulative Update. However, if you look at installed Exchange updates (be sure to click Installed Updates, within Programs and Features) it isn’t very clear that it is an interim update. In this case the only Exchange related update was KB2874216, which is regarded as a security update. It had it’s own set of problems resolved in the re-release. The version 2 of this update was released August 27th and it was installed on September 4th directly via Windows Update (no WSUS). Although the screen (see below) suggest that v1 was installed, I think it’s reasonable that v2 was installed. Also, the registry fixes weren’t manually applied but were correct (so there were no issues with content indexing). Click on picture to get a larger version:

image

However, after the failed CU2 install it wasn’t possible to remove this update. The uninstall starts, but just stops without any error window. Restarting the CU2 installation (an often successful strategy with Exchange 2010 rollup updates) also fails.

This was probably because lot of (Exchange) services were disabled due to the halted CU2 installation, which is expected. Unfortunately these services weren’t set to their correct state after exiting the update installer. They were not started and some did not start because their dependencies weren’t started.

After starting relevant services (most important: Remote Registry) manually I could remove the Interim Update. Funny thing was that a window appeared requesting the CU1 installation source; probably to restore the original files replaced by the security update (flashback to the Exchange 2003 era…). Just point to a folder with the extracted CU1 install. It will not remove Exchange. After that I could finally successfully install Cumulative Update 2 version 2 (CU2v2).

I’m not sure why this happened, whether this is a fluke or systematic. It appears to have occurred at least once before. Perhaps it doesn’t occur more frequently because Exchange admins are currently more hesitant to install updates quickly due to persistent quality issues. This scenario shows that it seems to be a wise strategy…


Update 25 September 2013
: I’ve found a similar case here, however it’s dated before the v2 release of KB2874216.


Update 25 September 2013 2
: Error message wasn't correct, extra unrelated information removed.

Update 27 September 2013: I can confirm this issue can be reproduced in a lab environment.

Without the security update, you can update from CU1 to CU2 without issue. With the security update, every time the error appears in step 3 Removing Exchange Exchange Files. See the screenshot:

LAB04-EX13C-2013-09-27-17-19-14

The ExchangeSetup.log basically shows the same information and doesn’t provide extra information.

After uninstalling this security update (see above for some tricks), the upgrade from CU1 to CU2 is successful.

There is no relation on Windows patches that I could detect and no relation on which Exchange role is installed (Multi, Client Access or Mailbox).

Todd Nelson also pointed towards the comments below this Exchange Team blog post where it is explicitly stated that security updates do not have to be removed before CU installation. It is in the comment section though, it could be that it is an unofficial remark.

Paul Cunningham correctly notes, that after CU2 has finally been installed successfully, you have to install the Security Update For Exchange Server 2013 CU2 (KB2874216). Let’s hope that the issue is fixed for CU3.

Update 27 November 2013: I've received several reports that this issue is still present while installing CU3. The same procedure described in this post still seems to work. I haven't confirmed this myself (yet).

In the meantime (even before CU3 was out) I also discovered that Server Component states could have the status inactive if the CU install failed and even if you eventually completed the CU install successfully afterwards. This is because the CU installer sets Components inactive with a requester (Functional) other than a lot of maintenance scripts or manuals use, it could be that with troubleshooting a different requester still has the component set to Inactive. So, best to check your Component States! You can see the state and the requester used to set the state in EMS with:

$states = Get-ServerComponentState -Identity <servername>
$states.LocalStates
$states.RemoteStates

You can set the state to active again with:

Set-ServerComponentState -Identity <servername> -Component <name> -Status Active -Requester <name requester>

Check this Exchange Team blog post on Exchange 2013 Server Components for more information on this subject, an important read even if you didn't have any issues while installing CU's. This was also discussed in The UC Architects podcast episode 30.

 

More Posts Next page »

Search

Go

This Blog

Syndication