A few notes on running Exchange in Microsoft Azure

Earlier this week Microsoft published a very interesting article: Exchange 2016 dev/test environment in Azure. I’m not a big fan of the how-to format of articles when the topic is around deployment because the guidance and specifics tend to change with later updates. There’s the risk of your article becoming obsolete sooner than planned.

The article contains an excellent real-world example of how to deploy a few virtual machines on Azure. I like how the author used PowerShell to configure the VM TCP/IP configuration and Install-ADDSForest to promote the server to domain controller.

Cool, let’s do this in production!

Although the article clearly states that the goal is the deploy Exchange for test and development, this article may spark new interest for people who would like to run Exchange in production too. The good news is that running Exchange in Azure is supported, but similar to running Exchange on other virtualization platforms some additional requirements must be met. The most significant requirement is actually mentioned in the article, in the section where storage is assigned for the Exchange VM:

This information can be found in the article Exchange 2016 virtualization as well:

Deployment of Exchange 2016 on Infrastructure-as-a-Service (IaaS) providers is supported if all supportability requirements are met. In the case of providers who are provisioning virtual machines, these requirements include ensuring that the hypervisor being used for Exchange virtual machines is fully supported, and that the infrastructure to be utilized by Exchange meets the performance requirements that were determined during the sizing process. Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.

Running a single VM with the proper resources for Exchange 2016 24/7 in Azure is probably more expensive than you would think, with prices starting around € 500,- per month for the VM, two small premium storage disks and a Windows license.

While this falls outside of the scope of the article we’re discussing here, I would like to mention the requirement to use a smart host for outbound email delivery if you choose to run Exchange in Azure.

Make sure you do the math and understand the requirements before using this article as an alternative deployment plan for your next Exchange server. At this moment I am not aware of any organization running Exchange servers in Azure for production. If you are doing this, please reply in the comments.

But wait, there’s more

As I mentioned in my introduction Exchange installation how-to articles often contain wrong or obsolete information. Unfortunately that applies to this article too.

The latest version of Exchange, that’s actually great advice. Unfortunately the url https://go.microsoft.com/fwlink/p/?LinkId=747753 links to the download page for Exchange 2016 CU1. Not only is this version much older than the latest version, currently CU4, more importantly this version of Exchange is not even supported to run on Windows Server 2016. It was Exchange 2016 CU3 that introduced support for Windows Server 2016, although CU4 is recommended because a compatibility issue in Server 2016.

Exchange 2016 not supported for virtualization?

And while making some screenshots for this article I found another gem. On the page with the requirements for virtualization is this weird segment:

This is actually a left-over from the Exchange 2007 era, where this modernized virtualization policy was introduced. The requirement on that page was that Exchange 2007 SP1 was required and list of supported guest operating systems indicated that running a VM with Windows Server 2003 x64 was not supported.

With every new edition (2010, 2013, 2016) this page was copied without much changes. Instead of remove this no longer relevant section, the writers updated the section whit what they thought made sense. That’s what a VM running Exchange requires that it’s running Exchange 2010.

But I digress, back to Exchange 2016 now. The current version of this page does not include Windows Server 2016 as a supported operating system for running an Exchange 2016 VM. While this is obviously a mistake, technically speaking a virtualized Exchange 2016 server installed on Windows Server 2016 is currently not supported.

I found a doc error too, what should I do?

Shoot an email to Ex2013HelpFeedback@microsoft.com and make sure to include the url of the page, a quote and/or screenshot of the text you’re referring to and an explanation of why you think it’s in error. The team behind this alias is awesome and almost every time you will receive a response from an actual person.

Exchange 2013 CU11 and Exchange 2007/2010 Update Rollups released

Microsoft today announced the release of the 11th Cumulative Update for Exchange 2013. That's not all, Exchange 2010 SP3 receives Update Rollup 12 and there's even one for Exchange 2007: UR 18. The latter is basically a DST update so don't expect any other issues to be fixed after you install this update.

Click the link to read more. One more thing, make sure you read this article on the Exchange Team Blog too: Exchange Management Shell and Mailbox Anchoring. This change in behavior may impact the way you manage Exchange with PowerShell. There's been some concern in the community about the benefits of this change, some people suggest that it introduces more problems than is solves. More about this subject on Reddit: Major change to how PowerShell works with Exchange

Now the wait is for Exchange 2016 CU1 which will be released with the next set of semi quarterly updates at the end of 2016Q1.

Install an older Exchange version after last server was removed

Consider a scenario where an Exchange environment was upgraded from let’s say Exchange 2007 to Exchange 2010 (I know, old versions). Some time after the admin removed the last Exchange 2007 server they find out that they a LOB application is not working correctly and they need to add a server with Exchange 2007 to allow it working again. The question is: can we add an older Exchange version after we removed the last server from the environment?

A community member on Reddit’s ExchangeServer community recently stated that this would not be possible:

…you won't be able to install a new 2007 server into a forest with 2010 servers once you've removed the last 2007 server…

In a follow-up discussion the poster referred to this article as his source:

Question: Is it possible to install Exchange 2003 or 2007 in a pure Exchange 2010 organization?
Answer: [...] If you have transitioned from Exchange 2007 to Exchange 2010 and the last Exchange 2007 server has already been decommissioned, the answer is again no. You will not be able to install Exchange 2007 at a later time in this organization because it’s now considered a pure Exchange 2010 organization.

This excerpt is from an article in the TechNet Magazine and was written by a well-known Exchange export so I don’t blame the Reddit poster at all. However, with my knowledge of how Exchange works I could not think of any reason why this shouldn’t work and this is the first time I heard of it.

My position on this subject is that there is no reason why you should not be able to add an Exchange 2007 server in a Server 2010 forest after the last Exchange 2007 was removed.

From a technical perspective there’s nothing special happening after you remove the last Exchange 2007 server. The Exchange environment does not keep count of the number of Exchange 2007 servers and there’s no process that implements a blocker when the count reaches <1. Also there’s no such thing as a ‘pure Exchange 2010 organization’, unless you want to say that there are no other Exchange versions than 2010 in the environment.

Time to validate this in a lab:

1. Create a domain controller for a new forest, DFL and FFL set to Windows Server 2003
2. Add a server with Exchange 2007 SP3
3. Add a server with Exchange 2010 SP3
4. Move the mailboxes and OAB generation to Exchange 2010
5. Remove the Exchange 2007 mailbox database and storage group
6. Uninstall Exchange 2007
7. Add a server with Exchange 2007

As expected I was able to add the Exchange 2007 server to the environment without any issues.

Now in a real world environment there can be other factors involved but’s it’s good to understand that your Exchange organization does not add a block when you remove the last server of a certain Exchange version.

Is it possible to install Exchange 2016 on a domain controller?

Can we?

This is a question that comes up every now and then in the technical communities I’m involved in. Is it possible and supported to install Exchange on a domain controller? Often answered incorrectly with a variant of “not supported, unless you run SBS”. The official answer is a bit different: it is supported to install Exchange on a domain controller.

In fact, this is supported since Exchange 2000 and has not changed for every new version up to the recently released Exchange 2016. As we can find in the Exchange 2016 System Requirements page:

Installing Exchange 2016 on directory servers
For security and performance reasons, we recommend that you install Exchange 2016 only on member servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer running Exchange 2016. After Exchange 2016 is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.

So should we?

Supported but not recommended, why is that? There are multiple reasons why you should consider to install Exchange on a member servers.

Firstly both Exchange and an Active Directory domain controller are resource-intensive tasks. For instance, both need to cache data in memory for best performance and will try to claim resources to do so. Running both tasks on the same computer may impact the performance and end-user experience for both AD and Exchange.

Exchange supports an RBAC model which allows an organization to deploy the least amount of privileges to their admins to do their work. However, when an admin needs local administrative access to server which has Exchange installed he gains administrative access to Active Directory too. This would enable the admin to elevate their own privileges which of course is a security risk.

A domain controller with Exchange installed cannot be demoted to remove AD from the computer as long as Exchange is installed, the last version that did support this was Exchange 2000. This may mean that at some later time an organization may find they can’t remove domain controllers from their environment without removing Exchange from the server first. In the recent past this is something that organizations often encountered when they needed to remove Windows Server 2003 domain controllers in order to be able to raise the domain or forest functional level. By the way, you also can’t promote a server with Exchange already installed but that is a much less common scenario.

I briefly touched the subject of security when discussing your admins working on this server, security needs considered with user access in mind too. Some firewall ports need to be forwarded to this server to accept email and give access to OWA/Outlook on the web, ActiveSync, Outlook Anywhere and maybe even legacy protocols as POP3 and IMAP4. Nowadays Exchange is considered secure enough to expose it to the internet directly but do you want to allow hackers to target your domain controller too? Opening firewall ports to allow access from the internet to your domain controller is not something I would call a security best practice.

There’s even more reasons why you should not install on a Exchange server but I won’t do into too much details here. Use your favorite search engine to do a search on this topic and you will find a ton of discussions about this subject.

Yeah, but what if…?

I am aware that for some very small organizations it may not make sense to purchase additional hardware and Windows Server licenses. Certainly not from a cost perspective. With a small load it’s unlikely that performance is going to be an issue and many small business owners will consider the security implications something for large enterprises to be concerned about. After all, Microsoft until recently sold the Small Business Server products that did install Active Directory, Exchange, SharePoint, ISA/TMG and even SQL on a single box. If that was an acceptable solution, why shouldn’t we do that with just AD and Exchange?

Running Exchange on a domain controller is a supported solution and as long as you understand the impact, go ahead and deploy that single server. When performance, security and flexibility play a role and the budget or infrastructure allows for, it’s recommended to deploy a new Windows server and install Exchange on that server.

How to remove the Exchange Autodiscover SCP

Consider a scenario where you moved all your user’s mailboxes to Exchange Online, for instance after a cutover or staged migration and want to remove any dependencies on the local Exchange server. You may find that Outlook still connects to the local Exchange server for Autodiscover lookups, this is because Outlook is hard-coded to query an AD Service Connection Point to locate a server with the Autodiscover service. When this fails Outlook falls back to the next DNS based methods or uses a local XML file.

Exchange Management Shell

There are multiple ways to prevent Outlook from contacting the local Exchange server first, some of them make more sense than others. The preferred way is to use the Exchange Management Shell to clear the entry for the Client Access server from the SCP.

Set-ClientAccessServer –Identity ServerName -AutoDiscoverServiceInternalUri $null

This removes the SCP entry for this Exchange server.

ADSIEdit

If the above method can no longer be used a low level AD editor as EDSIEdit can be used to remove the SCP manually. The full path of the SCP is:

CN=ServerName,CN=Autodiscover,CN=Protocols,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName,DC=Suffix

This object to remove has the Class type serviceConnectionPoint.

Alternative methods

One of the above steps is basically all you need to do. Alternatives include adding an ExcludeScpLookup value to the \Autodiscover registry key (KB article) and some articles even let you remove the Autodiscover virtual directory from IIS. This will of course make Outlook unable to query the local Exchange server for Autodiscover but why should you if you can simply remove the SCP.

How to verify?

As always, the proof is in the pudding. Use the Outlook test E-mail AutoConfiguration feature to verify the clients behavior. We’re specifically interested in the Log tab where we should see that Outlook is no longer able to query the SCP to obtain the Autodiscover url.

To start the Test E-mail AutoConfiguration tool, follow these steps:

1. Start Outlook.
2. Hold down the Ctrl key, right-click the Outlook icon in the notification area, and then click Test E-mail AutoConfiguration.
3. Verify that the correct email address is in the E-mail Address box.
4. In the Test E-mail AutoConfiguration window, click to clear the Use Guessmart check box and the Secure Guessmart Authentication check box.
5. Click to select the Use AutoDiscover check box, and then click Test.

Earlier I wrote a short article about this tool, unfortunately available in Dutch only: Autodiscover testen met Outlook. But you’ll get the general idea. Focus on the first or third tab when you’re interested in the Autodiscover results, read the Log tab when you're interested in the Autodiscover process.

Using Exchange 2007? Do not upgrade to Outlook 2016

In case you missed it, this week Microsoft released the new Office suite: Office 2016. Of course the latest version includes an updated version of Outlook too. Many people are eager to explore the new version of Office and others found their Office was automatically updated to Office 2016. From an Exchange perspective it’s important to be aware of the fact that Outlook 2016 does not support connections to Exchange 2007.

Customers who upgrade to Outlook 2016 and try to connect to their Exchange 2007 mailbox see this error message presented: The resource that you are trying to use is located on an unsupported version of Microsoft Exchange. Contact your e-mail administrator for assistance

This information can of course be found in the Office System Requirements, but you have to look for it:

Technically speaking there are workarounds available such as have Outlook 2016 access the Exchange 2007 server with the IMAP4 or POP3 protocol, but this of course introduces serious limitations and is not comparable with connecting through a MAPI or Outlook Anywhere connection.

Microsoft released an article which describes this issue and instructs Office 365 Personal, Office 365 Home, or Office 365 University users who's Outlook was automatically upgraded to Outlook 2016 to contact Microsoft Support to assist with a roll-back to Office 2013. See Error: Unsupported version of Microsoft Exchange error when you use Outlook 2016 to connect an Exchange 2007 account.

By the way, if your organization is still using Exchange 2007 you may want to look into an upgrade to a more recent Exchange version or Exchange Online. Exchange 2007 is in the Extended Support phase since 2012 and will go out of support in April 2017.

Is your 'free' Exchange hybrid key really free?

And I'm not talking about Willy or Nelson Mandela, I mean free as in at 'at no additional cost'. There are numerous sources on the internet stating customers can obtain a free key for their hybrid server. What most articles forget to mention is that the license restrictions make this license free for just a very small subset of all customers.
And it's not just blog posts of independent writers, I heard Microsoft employees state the same while visiting customers and in presentations on tech conferences as MEC and TechEd. And even their new Exchange Hybrid Product Key Distribution wizard (http://aka.ms/hybridkey) does not mention all requirements.

In fact there are three major requirements to obtain the license key for free:

• You have an existing, non-trial, Office 365 Enterprise subscription
• You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key.

And the one I want to emphasize:

• You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization

So if you're running licensed servers with Exchange 2010 in your environment, that Exchange 2013 server you want to deploy for hybrid is not free! In other words, the hybrid server license key is free if you're running Exchange 2007 or Exchange 2003 and have licenses for just those versions of Exchange.
In all other situations you will need to license your hybrid servers properly.
These license limitations can be found in the following KB article: How to obtain an Exchange Hybrid Edition product key for your on-premises Exchange 2007 or Exchange 2003 organization.

Exchange 2010 in Extended Support phase, last scheduled UR released today

Exchange 2010 entered the Extended Support phase earlier this year. Basically this means that only security updates will be released to all customers. New and improved features will no longer be added and non-security bugs will be not always be fixed.

Exchange 2010 is a little bit special because it's currently the most widely deployed version of Exchange. And why not, the HA model with the DAG works like a charm, the product is stable and mature and has all the features you can think of. Of course the web interface is looks a bit outdated but it works very well.

The question is if and when customers should upgrade from something that runs pretty well. There is some similarity with Exchange 2003 in the Exchange 2007 and early 2010 timeframe, the software was outdated but it worked very well. This is why so many customers kept running Exchange 2003 until and past the end of Extended Support phase.

Today Microsoft announced Update Rollup 10 for Exchange 2010 SP3. The list with resolved issues counts only 7 bullets.

Very interesting is this little remark at the bottom of the announcement on the Exchange team blog:

Update Rollup 10 is the last scheduled release for Exchange Server 2010. Both Exchange Server 2010 and Exchange Server 2007 are in extended support and will receive security and time zone fixes on-demand on a go-forward basis.

So if you're running 2010, now would be a great time to start planning your upgrade to Exchange 2013, which is rock solid with the 9th CU released today, or Exchange 2016 which is scheduled for release later this year.

Exchange Best practice: Increase the Application log file

Exchange is known as a chatty application when it comes to the Application log. And even while most of the information nowadays is written to the crimson channel, the classic Application still is a great source of information when you need to troubleshoot an issue.

The default settings of the Application log are a maximum size of 16 MB and older events are then overwritten when the log has reached that size. Now this may seem a lot, but can be be only a few hours of information for a busy server in a large environment. Good luck troubleshooting that issue that happened yesterday.

I know some of you are already doing this by default on a new Exchange server deployment, but you should definitely increase the log file size to a larger value. This can be done with the Limit-Eventlog cmdlet.

Limit-EventLog -LogName Application -MaximumSize 100MB

Or on all your Exchange servers at once:

Get-ExchangeServer | % { Limit-EventLog -LogName Application -MaximumSize 100MB -ComputerName $_.name  }

Well, you get the idea. More information: Limit-Eventlog

VMware, let's talk about Exchange and best practices

Apologies for the weird spacing, apparently Google changed something so Windows Live Writer can't post to Blogger currently. Posted this via a very weird work-around.

This week I was made aware of some VMware articles and whitepapers about running Microsoft Exchange on VMware VSAN. VMware VSAN is a 'virtual SAN' solution that employs local server storage and presents this to the hypervisor as a pool of shared storage, similar to the approach of Nutanix.

What surprised me, besides the mud slinging between VMware and their partner Nutanix, is the Exchange environment VMware built to execute their performance testing with.

I won't go into the details of the VSAN storage technology in this blog post, nor cover all aspects of the Exchange architecture design process. Today I want to focus on the high-level Exchange architecture used in the whitepapers.

The Exchange 2010 on VSAN whitepaper

First let's take a look at the 2014 whitepaper Microsoft® Exchange Server Performance on VMware Virtual SAN™.

Wait what? Exchange 2010 was used to perform the tests while Exchange 2013 was released almost two years earlier. Exchange 2010 was installed on Windows Server 2008 R2 while Server 2012 was available. Using older software to demonstrate your platforms capabilities may be done for very good reasons, however they were not explained in the whitepaper.

Microsoft introduced server roles in Exchange 2007 and soon discovered the new roles confused the crap out of their customers. So in the Exchange 2010 time-frame the Exchange team started to emphasize why combining the Mailbox, Client Access and Hub Transport roles on a single server was the preferred way to deploy Exchange. Most important reason: less complexity. And with that of course comes a decrease in costs, better reliability and more good things.

There have been situations where multi-role was not the most efficient option. Back when Exchange 2010 was released the most dominant hypervisor vendor was not able to assign more than 4 vCPU to a VM and when they were, they charged extra for that capability. As far as I know none of these limitations apply today so it's unclear why VMware did not deploy Exchange as recommended.

The Exchange 2013 on VSAN 6.0 whitepaper

The updated version of this whitepaper can be found here: Virtualizing Microsoft Applications on VMware Virtual SAN, Reference Architecture. In this whitepaper VMware explains how to deploy a HA Exchange 2013 environment while using the VSAN solution as the storage back-end.

Now starting with Exchange 2013 the Exchange team went a step further and consolidated their recommendations in the Preferred Architecture. This architecture was presented on industry conferences as MEC, TechEd and recently Ignite. In fact, the first article Microsoft released about Exchange 2016 contains a section called Preferred Architecture where the team explains the Exchange 2013 PA remains valid, with some minor updates.

Now let's compared the PA with the architecture VMware describes in this whitepaper.

First of all VMware did not deploy multi-role servers, they deployed 8 Exchange 2013 server where 4 could've done the trick. More servers equals an increase in complexity and costs.

The placement of the "DAG File Cluster" is a bit confusing too, especially because the Exchange Mailbox servers and the FSW are connected by a blue line. I wonder if the author understands the role of the FSW for the cluster.

Database and log files are isolated, this isn't required. And 80 GB is not sufficient for the OS (32 GB), page file (32 GB + 10 MB) and Exchange (30 GB).

VMware uses two network adapters, which nowadays is no longer the best practice.

Not just VMware, Citrix too

Recently I commented on some Exchange whitepapers by Citrix and today I looked at two whitepapers by VMware. Both vendors demonstrate they have limited understanding of Microsoft Exchange and the best practices Microsoft wrote.

Let me be honest. IT has been never more challenging as today. Customer's environments are growing in size and complexity. Trends like virtualization (server, network, storage, application, etcetera), BYOD, consumerization of IT, cloud computing and increasing demands from the business can drive an IT person crazy. This is why it has never been so important for vendors to reduce complexity, make sure recommendations are in line with other vendors and that customers receive all the help they need to implement the solutions in the best way possible.

As an Exchange consultant I often sat with customers discussing Microsoft best practices for Exchange and the storage or virtualization guy showing up with an outdated or slightly inaccurate document instructing the exact opposite. Customers expect the vendors to help them clarify stuff, not to cause even more confusion.

So Citrix, VMware and other vendors too, time to step up your game. Make sure you read and understand every article on the official Exchange Team Blog. Update your whitepapers during their lifetime when progressive insight or updated best practices require it. Ask Microsoft for feedback or involve Subject Matter Experts to review your document and provide some feedback from their perspective. I'm sure that with a little extra effort the quality of the whitepapers can improve a lot.

PAL tool now works with Exchange 2013!

PAL or Performance Analyzer for Logs is a handy tool to assist with performance monitoring and troubleshooting. Many Exchange admins have used this tool to quickly create a performance counter set and scan the results against a threshold file. PAL outputs a report with easy graphs and performance alerts. This report is a great help to get a quick overview of the performance of a server and indication of possible performance bottlenecks.

Unfortunately there was no threshold file for Exchange 2013, partly because Microsoft never published the detailed performance counter information as they did for 2007 and 2010. I am very excited that Adrian Moore (admoore@microsoft.com) found the time to write the threshold file for Exchange 2013, which is included with PAL version 2.7.3.

Download PAL and read more at the PAL site on Codeplex.

Windows Mobile does not support your new SSL certificate

The world is moving away from SHA-1 certificates, which is a good thing from a security perspective. Major vendors like Microsoft and Google are forcing Certificate Authorities to give out certificates with the new SHA-256 hashing algorithm. They do this by simply stop trusting root CA’s which give out SHA-1 certificates after a certain date.

What can you do? Not much actually, because every new SSL certificate you purchase or renew will be SHA-256. Of course there are old operating systems which don't support SHA-256, for instance XP versions older than SP3 and Server 2003 without SP2 installed. So basically every modern OS and even much older versions support SHA-256.

Now for us Exchange guys there may be an exception, this is Windows Mobile 5 and 6 which do not support SHA-256. Yes, this operating system is very old and has been superseded by Windows Phone 7 and newer. However, it has been sold until not very long ago and products with Windows Mobile may be still available. An example of such a device is the Samsung Omnia 735.

So if you have any users with a Windows Mobile device and are planning to renew your Exchange SSL certificate, please be aware of this issue. Depending of your situation you may consider replacing the devices or even move to SHA-1 certificates which are signed by your own CA. This obviously is not a safe long-term solution but it may buy you some time before you can move to SHA-256 certificates.

Security-update beschikbaar voor Exchange 2007, 2010 en 2013

Microsoft heeft een fix uitgebracht voor Outlook Web App in alle ondersteunde versies van Exchange. Het gaat om vier verschillende issues, drie daarvan komen alleen in Exchange 2013 voor en de vierde ook in Exchange 2007 SP3 en 2010 SP3. In alle gevallen gaat het om beveiligingsproblemen die zijn aangemerkt als Important.

Zoals alle beveiligingsupdates worden ook deze aangeboden via Microsoft Update, maar wie dit voor wil zijn kan ze handmatig downloaden:

Exchange 2007 SP3

Exchange 2010 SP3

Exchange 2013 SP1

Exchange 2013 CU6

Versies die hier niet bij staan worden niet meer ondersteund of zijn niet kwetsbaar. Lees voor meer informatie het security bulletin MS14-075: Vulnerabilities in Microsoft Exchange Server Could Allow Elevation of Privilege (3009712)

Autodiscover testen met Outlook

Outlook die zijn eigen profiel configureert zonder dat de gebruiker hier iets aan hoeft te doen, en het werkt ook voor ActiveSync! Het kan sinds Exchange 2007 en Outlook 2007, maar Autodiscover heeft van het begin af voor verwarring gezorgd. In dit artikel ga ik niet in over de exacte werking maar laat ik een 'client-side' troubleshooting tool zien die ons zowel de werking van het proces laat zien, als de daadwerkelijke informatie die de client van de Autodiscover Service krijgt.

Je hebt nodig:

• Outlook 2007 of hoger
• Een Outlook profiel

Dat Outlook profiel mag een leeg profiel zijn of eentje met nepgegevens, bijvoorbeeld voor POP3 en SMTP.

Zoek het Outlook icoontje in de System Tray, klik er met de rechtermuisknop op terwijl je CRTL ingedrukt houdt. Kies nu Test E-mail AutoConfiguration:

Wanneer je als AD gebruiker op een AD member computer ingelogd bent leest Outlook het windowsEmailAddress attribuut uit en vult deze alvast in. In alle andere gevallen vul je je mailadres en wachtwoord in. Haal de vinkjes voor Guessmart weg.

Klik nu op Test, waarna Outlook een Autodiscover lookup gaat doen met de hierboven ingevulde gegevens. Afhankelijk van de configuratie kan dit even duren, het is dan ook interessant om tijdens het uitvoeren direct het tabblad Log in de gaten te houden, hier kunnen we de voortgang van het proces volgen:

In dit geval gaat het om een Office 365 mailbox waarbij het proces wat complexer is, maar het belangrijkste is dat de laatste regels aangeven dat het proces geslaagd is. Bij een ander resultaat betekent dit dat je de stappen doorleest en na gaat of ze overeenkomen met de wijze waarop je Autodiscover geconfigureerd hebt.

Dan terug naar het tabblad Results, deze geeft het ontvangen resultaat netjes weer maar bevat feitelijk dezelfde informatie als de ruwe XML die we op het derde tabblad kunnen zien.

Op deze plek controleren we de daadwerkelijk ontvangen informatie, grotendeels bepaald door wat we als InternalURL en ExternalURL waardes hebben geconfigureerd in Exchange.

Met dit handige hulpmiddel wordt het troubleshooten van Autodiscover een stuk eenvoudiger.

Apple iOS 8.x en issues met vergaderverzoeken

Het was een tijdje rustig op dit front maar in de nieuwste versie van de software voor Apple's iPhone en iPad zit een bug die vergaderverzoeken verminkt. Dit gebeurt wanneer de gebruiker eerst eigenschappen aanpast, zoals het veranderen van de Show As status, aanpassen van de Alert value of het toevoegen van een commentaar voor de organisator, en het verzoek pas daarna accepteert.

In deze gevallen kapt iOS de body van het bericht af na 500 karakters. Zo kan het gebeuren dat HTML of RTF berichten opeens als plain-text weer worden gegeven of dat de url in een invite voor een Lync meeting halverwege afgekapt wordt.

Workarounds:

• Accepteer het verzoek eerst, pas dan pas de eigenschappen aan
• Zet het syncen van de agenda uit
• Stap over op de OWA app voor iPhone/iPad

Meer informatie in het volgende KB-artikel: Known calendaring issues with iOS 8.x devices

Belangrijke security-update voor Exchange

Op 11 november brengt Microsoft een aantal Security Bulletins uit, dit keer gaat het om 16 gemiddelde tot ernstige beveiligingsproblemen waarvoor een fix gemaakt is. Ditmaal zit er ook een security update bij voor alle recente en ondersteunde versies van Exchange: 2007 SP3, 2010 SP3, 2013 SP1 en CU6.

Het issue is geclassificeerd als Important en lost een probleem op waarbij een aanvaller zich rechten zou kunnen verschaffen op een server. Het advies is om Important updates bij de eerstvolgende gelegenheid te installeren. Dan weet je het alvast...

Meer informatie hier: Microsoft Security Bulletin Advance Notification for November 2014

Spamhaus RBL werkt niet met Google DNS

In mijn Exchange 2013 lab heb ik een Edge Transport server geconfigureerd om de Spamhaus Real-time Block List te gebruiken. Door een IP Block List Provider toe te voegen en de Connection Filtering agent in te schakelen test Exchange of de mailserver die een bericht wil afleveren niet op een RBL staat.

Helaas bleek dat bij mij niet te werken, dit werd bevestigd door een test met behulp van de Crynwr Spamhaus test. Raar, want het is een eenvoudige configuratie:

Add-IPBlockListProvider -Name Spamhaus -LookupDomain zen.spamhaus.org

De Connection Filtering transport agent staat standaard ingeschakeld, dat was het probleem dus ook niet. De volgende stap is het handmatig controleren of je een DNS query naar de servers van Spamhaus kunt doen. Dit kun je doen door een IP-adres te kiezen, bijvoorbeeld 127.0.0.2, en hiermee een query te construeren. Zet het IP-adres in omgekeerde volgorde en laat deze eindigen op .zen.spamhaus.org. In dit geval moeten we dus een DNS query doen voor 2.0.0.127.zen.spamhaus.org, het antwoord bevat een code die aangeeft of het IP wel of niet op de blocklist staat. En in dit geval zijn we niet geïnteresseerd in het antwoord maar willen we in eerste instantie controleren of de query überhaupt mogelijk is.

nslookup 2.0.0.127.zen.spamhaus.org

In dit voorbeeld gebruik ik een interne DNS-server waarvan ik de naam verborgen heb, maar in mijn lab mislukte deze test. De oorzaak bleek te liggen in de publieke Google DNS servers die ik als forwarder had geconfigureerd, dit zijn de populaire 8.8.8.8 en 8.8.4.4 adressen. Wanneer we dezelfde query uitvoeren tegen één van deze DNS-servers dan mislukt deze:

nslookup 2.0.0.127.zen.spamhaus.org 8.8.8.8

Bij nader onderzoek blijkt dat Spamhaus dit ook vermeldt in hun FAQ:

Check what DNS resolvers you are using: If you are using a free "open DNS resolver" service such as the Google Public DNS or large cloud/outsourced public DNS servers, such as Level3's or Verizon's, to resolve your DNSBL requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from Spamhaus' public DNSBL servers. We recommend using your own DNS servers when doing DNSBL queries to Spamhaus.

In andere gevallen kan er natuurlijk een andere oorzaak zijn, maar deze troubelshooting methode kan een eerste stap zijn om te controleren of je de servers van Spamhaus kunt raadplegen.

Bron

Werken met (legacy) Public Folders

Op dit moment heb ik het genoegen om te mogen werken met een grote hoeveelheid Public Folder data. Het doel is om deze te repliceren naar nieuwe databases. Hierbij gebruik ik een aantal scripts en tools die misschien handig zijn om te delen.

Overzicht

Als eerste heb ik een Excel-file gemaakt met een overzicht van alle folders, het aantal items hierin en de grootte in MB. Dit is weliswaar een momentopname maar het geeft je een goed beeld van de structuur en de grootste folders.

Get-PublicFolder -Recurse -ResultSize Unlimited | Get-PublicFolderStatistics | Select-Object Name,FolderPath,CreationTime,LastAccessTime,LastModificationTime,LastUserModificationTime,LastUserAccessTime,@{expression={$_.totalitemsize.value.ToMB()};label=”Size(MB)”},ItemCount | Export-CSV "C:\data\pfstats.csv"

Denk aan de -ResultSize parameter, anders krijg je met Get-PublicFolder alleen de eerste 10.000 resultaten. Dit bestand heb ik in Excel geopend, conditional formatting gebruikt om folders met veel items of data snel te kunnen herkennen en uiteraard opgeslagen als xlsx-bestand.

Aan de hand van dit bestand heb ik de top-level folder kunnen kiezen waarmee ik de replicatie wil starten. Ook heb ik kolommen toegevoegd voor de nieuwe databases zodat ik een check kan zetten als ik deze als replica toegevoegd heb. Dit helpt mij om overzicht te houden gedurende het proces.

Replica's toevoegen of verwijderen

Op de locatie waar Exchange geïnstalleerd is staat een \scripts directory. Omdat het installatiepad per server verschilt is er de $exscripts een variabele die we in Exchange Management Shell kunnen gebruiken om de scripts te lokaliseren.

In dit geval gebruik ik het AddReplicaToPFRecursive.ps1 script om de nieuwe database als replica toe te voegen op een toplevel folder en alle onderliggende folders:

cd $exscripts
./AddReplicaToPFRecursive.ps1 -TopPublicFolder "\MyFolder" -ServerToAdd NewServer1

Op een later moment gebruik ik het RemoveReplicaFromPFRecursive.ps1 om de oude replica te verwijderen. Een alternatief zou het gebruik van het MoveAllReplicas.ps1 script die beide stappen in één keer doet. Meer informatie over deze scripts vind je hier: Scripts for Managing Public Folders in the Exchange Management Shell

Rapportage en monitoring

Om op hoofdlijnen te zien op de replicatie plaats vindt, gebruik ik het volgende commando die de grootte van het .edb-bestand geeft:

Get-PublicFolderDatabase | Select Server, Name, @{Name="Size (GB)";Expression={$objitem = (Get-PublicFolderDatabase $_.Identity); $path = "`\`\" + $objitem.server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1048576KB; [math]::round($size, 2)}}, @{Name="Size (MB)";Expression={$objitem = (Get-PublicFolderDatabase $_.Identity); $path = "`\`\" + $objitem.server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1024KB; [math]::round($size, 2)}}

Deze one-liner ziet er misschien complexer uit dan hij is, dat komt omdat we het UNC pad moeten samenstellen om de grootte van het bestand te kunnen meten. Een andere stukje code is om de grootte om te rekenen naar GB en MB.

Door dit commando af en toe te herhalen zie je al snel dat het aantal GB's van de nieuwe databases toeneemt. Dit is natuurlijk niet voldoende om een goed beeld van de status te krijgen. Dus na enige tijd heb ik het Exchange 2010 Public Folder Replication Report van Mike Walker gebruikt.

Dit script gebruikt Get-PublicFolder en Get-PublicFolderSatistics om informatie over de public folders te vergaren. Omdat dit zeer lang kan duren, al snel enkele uren bij een paar duizend folders, beperkt ik het rapport tot een specifieke top-level folder:

.\Get-PublicFolderReplicationReport.ps1 -FolderPath "\MyFolder" -Recurse -ComputerName @("OldServer1", "OldServer2", "NewServer1", "NewServer2") -AsHTML -Filename report.html

Het resultaat is een zeer bruikbaar rapport in HTML-vorm.

Troubleshooting

Op basis van de bestandsgrootte was al duidelijk dat één van de nieuwe databases niet volledig gevuld werd en het HTML-rapport bevestigt dat. Om uit te vinden of er een probleem is heb ik het logging level voor een aantal relevante bronnen op de bron- en doelserver aangepast van Lowest naar High:

Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Incoming Messages" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Outgoing Messages" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication NDRs" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Backfill" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication Errors" -level high
Set-eventloglevel -Identity "OldServer1\MSExchangeIS\9001 Public\Replication General" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Incoming Messages" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Outgoing Messages" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication NDRs" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Backfill" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication Errors" -level high
Set-eventloglevel -Identity "NewServer1\MSExchangeIS\9001 Public\Replication General" -level high

Na enige tijd verschijnen er in het Application eventlog allerlei meldingen van source MSExchangeIS Public Store. Op zich zou ik die met PowerShell kunnen analyseren (Get-EventLog) maar voor een snel overzicht heb ik de Event Viewer gemaakt en een filter op source MSExchangeIS Public Store gezet.

De grote hoeveelheid errors bleken vals alarm te zijn, deze waren onschuldig en geen indicatie voor een daadwerkelijk probleem.

Om eventuele fouten te repliceren heb ik de replicatie voor een (op de nieuwe server niet gevulde) folder handmatig gestart:

Update-PublicFolder "MyFolder\SubFolder" -Server OldServer1

Op dit moment zie je direct de bijbehorende replicatie-events verschijnen op de bron- en doelserver. Vervolgende de statistieken voor deze folder opgevraagd op de oude en nieuwe server:

Get-PublicFolderStatistics "MyFolder\SubFolder" -Server OldServer1
Get-PublicFolderStatistics "MyFolder\SubFolder" -Server NewServer1

Na een paar minuten gaf de folder op de nieuwe server het zelfde aantal items als de oude. Daarom ook de rest van de folders nogmaals laten updaten:

Get-PublicFolder "MyFolder\SubFolder" -Recurse -ResultSize Unlimited | Update-PublicFolder -Server OldServer1

Daarna het Public Folder Replication Report nogmaals uitgevoerd en uitsluitend groene vlakjes gezien.

Tips

Met name bij het werken met grote hoeveelheden folders duren eenvoudige taken als het opvragen van folders of statistieken zeer lang. Plan dus vooruit en voorkom dat je langlopende taken opnieuw moet uitvoeren. Sla het resultaat van een query op in een CSV-bestand of variabele.

Deel de hoeveelheid data op in behapbare blokken, bijvoorbeeld een toplevelfolder met onderliggende mappen die voldoende items bevatten maar pakweg een paar GB groot zijn. Selecteer hiervoor desnoods een dieper gelegen folderstructuur. Besteed aandacht aan het verloop en zorg dat je goed inzicht hebt in het verloop of eventuele problemen. Los die eerst op en ga dan verder met de rest van de data.

Dit artikel heeft betrekking op Exchange 2010 maar is ook bruikbaar voor Exchange 2007. Om Public Folder replicatie goed te begrijpen moeten we terugvallen op documentatie voor Exchange 2003, afgezien van de gebruikte tools is er in Exchange 2007 en 2010 namelijk weinig veranderd. Een goed stuk documentatie is: Controlling Exchange Server 2003 Public Folder Replication

En daar is het derde issue met Exchange 2013 CU6...

Ik krijg nog wel eens het verwijt dat ik te kritisch ben en ook de positieve kant van de zaak moet belichten in mijn artikeltjes. Daar ga ik eens even goed over nadenken en zodra ik het ontdekt heb dan laat ik het direct weten. Maar nu kan ik niet anders dan diep zuchten en vertellen dat een derde serieus issue is opgedoken in Exchange 2013 CU6.

You cannot route ActiveSync traffic to Exchange 2007 mailboxes after you upgrade to Exchange 2013 CU6

Deze komt dus naast de al bekende issues:

• Exchange Server 2013 databases unexpectedly fail over in a co-existence environment with Exchange Server 2007
• Exchange Online mailboxes cannot be managed by using EAC after you deploy Exchange Server 2013 CU6

En laat ik voor de volledigheid ook verwijzen naar de fix voor de fix in dat laatste artikel: Exchange2013-KB2997355-FixIt-v2 (Michel de Rooij)

Het issue waar het ditmaal om gaat is dat Exchange 2013 CAS een ActiveSync verzoek voor een gebruiker op Exchange 2007 niet correct kan authentiseren, laat staan verder verwerken.

Even een reminder, je weet waarschijnlijk dat Exchange 2013 CAS alle verzoeken voor mailboxen op Exchange 20007, 2010 ofwel Exchange 2013 servers in een andere site 'proxied' naar een andere CAS server. Een uitzondering is EAS voor Exchange 2007 mailboxen, deze wordt geproxied naar Exchange 2013 Mailbox die het verzoek vervolgens proxied naar Exchange 2007 CAS. Zie Client Connectivity in an Exchange 2013 Coexistence Environment

Bij eerdere issues traden er al problemen op met de EAS Application Pool op de 2013 Mailbox server wanneer hij een verzoek wil proxien naar 2007 CAS. Bij dit meest recente issue komt het probleem dus al voor op Exchange 2013 CAS.

Er is inmiddels een hotfix beschikbaar met de naam Exchange2013-KB2997209_2997847-x64-en.msp. Zoals de naam al verklapt verhelpt deze update beide Exchange 2007 coexistence issues.

PowerShell Oneliner: Wanneer was de laatste backup van de Exchange mailbox databases?

Vraag de mailbox databases op met de -Status parameter, anders zijn properties als LastFullBackup leeg. Sorteer deze in omgekeerde volgorde en geef ze weer in een tabel:

Get-MailboxDatabase -Status | sort lastfullbackup -Descending | ft name,lastfullbackup