Category Archives: Technical

ECP Language without a mailbox and specify Exchange version

ehlo!

You are using your admin account for administrating Exchange, right? If not – you are on the bad side of life 🙂

So when there is no mailbox available ECP will be shown in the primary language your browser is configured to. If you want to change this just use the correct URL.

For instance https://localhost/ecp/?mkt=EN-us will always use the English locale.

During a migration where your mailbox still resides on Exchange 2007 or 2010 and you want to configure Exchange 2013 settings please use: https://localhost/ecp?ExchClientVer=15

Same will work if you want to use Exchange 2010 ECP: https://localhost/ecp?ExchClientVer=15

Your EXGuru – aka Peter Forster – aka Satschent Peter

Autodiscover? – What? – Deep Dive Series Part 3

ehlo!

You’ve already seen Part 1 and Part 2 – right?

Now the Autodiscover.XML file does have some more informations for Outlook to use. One very important URL to use are the Exchange Web Services. Normally for sending and receiveing an E-Mail the EWS configuration is not necessary. But as soon as your users try to configure their Out of Office Assistant (OOF) they use EWS to do this. So when the URL of EWS is not available useres are unable to configure OOF.

Also the information for OWA and the Offline Address Book (OAB) will be configured with the XML.

To check the client configuration use the “Test e-Mail Autoconfiguration” feature from Outlook. Search your clock on your desktop (hint – right bottom corner) and search the Outlook symbol. SHIFT+right-click and choose “Test E-Mail AutoConfiguration”

ContextOutlook

From here you can test your Autodiscover configuration. Remove both options for “Guessmart” (this is for POP3 and IMAP testing) and click Test.

The results will now be shown. The tab Log will provide the information how Outlook was able to find the autodiscover.xml file. As stated in Part 1 a domain joined client will use the SCP. If this is for any reason not successfull it will look like that:

Autodiscover_not_working

Outlook will try the different options (see Part 1) to get the XML file. If it is not successful it will keep retrying it until the last option – search for an SRV-Record even does not work:

Autodiscover_not_working_1

So Outlook was not able to get an XML file.  Also this will be stated on the Results tab.

Autodiscover_not_working2

Now it is time to check why this happens.

 

Your EXGuru – aka Peter Forster – aka Satschent Peter

Autodiscover? – What? – Deep Dive Series Part 2

ehlo!

Part 1 of our Series introduced the Service Connection Point. Now when Outlook tries to reach the SCP it will get a response with a Servername and an URL (you remember?)

Outlook now tries to reach that URL because it is interested to get the information provided within the XML. The response of Autodiscover from an Exchange 2016 Server after a default installation will look like this:

Here we can see a lot of information. Let’s break down the information to a few less and readable segments – for instance the protocol types EXCH and EXPR

<Protocol>
<Type>EXCH</Type>

<Protocol>
<Type>EXPR</Type>

The different type of protocols define the configuration to know if the connection is meant ‘internal’ or ‘external’
EXCH is the internal configuration
EXPR is the external configuration

The definition ‘internal’ or ‘external’ does not always mean the connection will be outside your network or inside. It depends on what DNS is getting back to your client when we try to reach for example our OWA URL https://webmail.domain.local/owa/

Outlook first tries to reach the internal URL. If this is sucessful the internal URLs will be used. If not – no response for example than the external URL will be used.

When Outlook was able to figure out on which URLs Exchange can be reached it tries to open that connection.

So keep one very important thing in your mind: Autodiscover is simple the process to send an XML file to Outlook so that it does know where it should connect. Not more or less.

Your EXGuru – aka Peter Forster – aka Satschent Peter

Autodiscover? – What? – Deep Dive Series Part 1

ehlo!

Everyone is talking about Autodisover in Exchange and since Exchange 2013 it is more important than ever. But did you really know how the process works?
I know – there are plenty of blog posts out in the internet but I thought I start the challenge from scratch and do it the complete way.

Let’s do some steps behind Autodiscover and what it is:
From an Outlook configuration perspective Autodiscover is just an XML file with some content – brought to you by your Exchange Servers. Outlook tries to find its configuration by using the Autodiscover-Service.

Outlook tries 5 ways to figure out where the Autodiscover XML File could be reached:

  • Service Connection Point in Active Directory (only for domain joined clients
  • SMTP-Domain: https://smtpdomain.tld/Autodiscover/Autodiscover.xml
  • Autodiscover HTTPS: https://autodiscover.smtpdomain.tld/Autodiscover/Autodiscover.xml
  • Autodiscover HTTP: https://autodiscover.smtpdomain.tld/Autodiscover/Autodiscover.xml
  • Autodiscover check for SRV lookup for _autodiscover._tcp.<smtpdomain>

Normally a domain joined client will always use the SCP. For this blog post we will figure out what the SCP is.

A Service Connection Point (SCP) is a property that can be found in the Configuration Partition within Active Directory. In it’s simplest definition it is a URL to your Exchange server. You configure this URL by setting the AutoDiscoverServiceInternalUri within the Set-ClientAccessServer (Exchange 2013) or Set-ClientAccessService  (Exchange 2016).

So with just one simple command you configure the SCP to reflect your Exchange Servers. After the default installation of Exchange the internal hostname will be listed there – for example: https://forpeex16-01.domain.local/Autodiscover/Autodiscover.xml

If you add another server a second SCP with https://forpeex16-02.domain.local/Autodiscover/Autodiscover.xml will be created.

Because of the namespace design in Exchange it is highly recommended to change this URL to something like https://autodiscover.domain.local/Autodiscover/Autodiscover.xml

Behind Autodiscover is your loadbalancer IP or if you do not have a loadbalancer the IP-Adresses of your CAS Servers (Exchange 2013) or Mailbox-Servers (Exchange 2016).

From an Outlook-Client perspective Outlook is configured to use the SCP on a domain joined machine. This is hardcoded in Outlook. OK – enough for today – I’ll have enough to say about Autodiscover the next time…

Your EXGuru – aka Peter Forster – aka Satschent Peter

Update Outlook before you migrate to Exchange 2013/2016

ehlo!

Many of you use Outlook to connect to your Exchange-Server, right?
When did you last update your Outlook to the latest version? Wow, you installed Service Pack 1 for Office 2013?
If yes than you have a very old version of Outlook.

Microsoft releases monthly updates to Outlook to keep Outlook Up-to-Date for you newest Exchange versions.

If you do not install those updates you can have the strangest errors. Worst case with very versions is that you are not able to connect to Exchange 2013/2016 at all.

My recommendation before starting a migration project: Update Outlook to the latest available version. And it is easy to follow the latest version.

Outlook – latest Hotfixes: Latest available Update for Outlook (MSI-based installation)
Office-Click-To-Run – latest Version: Office Click-To-Run – latest Version

Below you see the latest releases of Outlook 2010/2013/2016

Outlook 2016

Version-Number

Patch

KBArticle

16.0.4288.1000

Oktober 2015

https://support.microsoft.com/en-us/kb/2910976

16.0.4266.1003 – RTM

16.0.4229.1021 – Beta Preview

Outlook 2013 Click-to-Run

Version-Number

Latest release

Stand Oktober 2015

15.0.4763.1000

https://support.microsoft.com/en-us/gp/office-2013-365-update

Stand September 2015

15.0.4753.1002

At least Service Pack 1 with the latest updates.

Outlook 2013

Version-Number

Patch

KB-Artikel

15.0.4763.1000

October 2015

https://support.microsoft.com/en-us/kb/3085579

15.0.4753.1002

September 2015

https://support.microsoft.com/en-us/kb/3085495

15.0.4745.1000

August 2015

https://support.microsoft.com/en-us/kb/3055012

15.0.4727.1000

June 2015

https://support.microsoft.com/en-us/kb/3054855

At least Service Pack 2 with the following updates.

Outlook 2010

Versionsnummer

Patch

KB-Artikel

14.0.7160.5000

October 2015

https://support.microsoft.com/en-us/kb/3085604

14.0.7157.5000

September 2015

https://support.microsoft.com/en-us/kb/3085522

14.0.7155.5000

August 2015

https://support.microsoft.com/en-us/kb/3055041

14.0.7151.5000

June 2015

https://support.microsoft.com/en-us/kb/3054881

 

Your EXGuru – aka Peter Forster – aka Satschent Peter

Your Exchange DAG and WAN?

helo!

While many of our customers do have their Exchange nodes well connected some are asking: Can we put the second node of our DAG into a location where we have a hughe TCP round trip time?

The answer is: Yes and No. It depends? This was the answer you are searching for, right?

From a supportability perspective 500ms round trip time is the maximum supported value.

So now it is your decision to install the Node or not. BTW: An easy way to figure out the round trip time is to use pathping or ping. But hey – is ICMP only really the right thing to measure the round trip time?

Your EXGuru – aka Peter Forster – aka Satschent Peter

Put your DAG into Maintenance

helo!

You install Exchange Cumulative Updates as soon as they arrive, right? You do your daily job while maintaining Mailboxes and Distribution Groups?.
Now it is time to get in touch with the upgrade-process. While you know the details about PAM/SAM from my other blog posts we can directly head over to installing your next Exchange Cumulative Update.

Important things to note prior the upgrade:

  • Disable the OS Anti Virus Engine
  • Disable/Stop Backup Jobs or Windows Services with Active Connections to Exchange
  • Check your AD Backup with repadmin /showbackup
  • Check your Database Backup with Get-Mailboxdatabase -Status | fl Name,*backup*
  • The the above output for “Backup in Progress” Messages.
  • You use a loadbalancer? The the “Real Server” into Maintenance/Disable the Server on the Loadbalancer for new connections
  • You use DNS Round-Robin? Remove the DNS record for the node you want to patch
  • Be aware for some “Relay” DNS records where SMTP devices will send messages.
  • You use Microsoft Operations Manager (SCOM)? or any other monitoring solution? Put your Server into Maintenance!
So now we can start over, right?
Not yet buddy! First we need to set the PowerShell Execution Policy to unrestricted
Set-ExecutionPolicy unrestricted
If your Server do not have Internet Access please disable the option “Check for publisher’s certificat revocation”. This will save you hours of waiting.
IE_Revocation

Now lets get started with the fun – ready for copy and paste into your environment:

#Define the Server to update
$Servername="YOUR_SERVERNAME_HERE"
#Define the Server where to move the databases
$ServerToSwitch="YOUR_FQDN_SERVERNAME_HERE"
#Define the DAG Name
$DAGName ="YOUR_DAG_NAME_HERE"
 #Set the components into maintenance
Set-ServerComponentState $SERVERNAME –Component HubTransport –State Draining –Requester Maintenance
#Redirect all Messages to the server available during maintenance
Redirect-Message -Server $SERVERNAME -Target $ServerToSwitch
#PAM/SAM Move
Move-ClusterGroup –cluster $DAGName –name "Cluster Group" –node:$ServerToSwitch
#Suspend the cluster Node
Suspend-ClusterNode –Name $SERVERNAME
#Do not allow to mount databases (PAM and BSCC disabled)
Set-MailboxServer $SERVERNAME –DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer $SERVERNAME –DatabaseCopyAutoActivationPolicy Blocked
#Set Server Wide Offline for all Components
Set-ServerComponentState $SERVERNAME –Component ServerWideOffline –State InActive –Requester Maintenance
#Move all active Databases to the defined node.

Move-ActiveMailboxDatabase -Server $SERVERNAME -ActivateOnServer $ServerToSwitch

Your EXGuru – aka Peter Forster – aka Satschent Peter

BCS and BCSS – well known for any Exchange Admin

ehlo!

You have seen my last post about Active Manager. You are now familiar with PAM/SAM and BSC and BCSS. For all of you haven’t seen the article I’ll follow up on Best Copy Selection (BSC) and Best Copy and Server Selection (BCSS). BSC was the Exchange 2010 name for BCSS as it is called in Exchange 2013.

As soon as the Active Copy of a Database is no longer available BCSS tries to enable the best available copy. There are a few steps included in this process. One step is to decide the best available copy of the database. This will be done by checking the Mailbox-Server AutoDatabaseMountDial Setting. If the number of missing logfiles is equal or less than the value of AutoDatabaseMountDial Exchange tries to mount the database.
If the value is greater Active Manager tries to find another copy (if they are available) to be activated.

And why I’m discussing all this?
Because it is important during planned maintenance to set the Server into Maintenance that PAM knows not to activate that copy of a database. More about Maintenance will be available soon!

 

Your EXGuru – aka Peter Forster – aka Satschent Peter

Active Manager? – Never heard, right?

ehlo!

If you are using Exchange 2013 with a DAG setup you are familiar with the PAM or Primary Active Manager, right? And you are more familiar with SAM – the Secondary Active Manager – aren’t you?

The Active Manager runs within MSExchangeRepl.exe and manages the database copy between the Nodes within the DAG. PAM is the instance which decides which copy of a DAG should be Active.

Be aware: Exchange itself is not a clustered application. It just uses the Windows Failover-Cluster technology to do the job.

Important while do a planned upgrade from Exchange to a new Cumulative Update: Note: If your DAG have more nodes, you need first upgrade all non PAM nodes and then upgrade PAM node.

Details about PAM/SAM and more can be found here: Active Manager

Your EXGuru – aka Peter Forster – aka Satschent Peter

The little known secret about – Sizing your Exchange RAM

helo!

Sizing your Exchange server is a very common task for an Enterprise Architect like me. On a regular basis I will check the recommended Hardware-Sizing for our customers.

Many of our deployments are installed on physical boxes but some are also virtualized. In aspects of sizing there aren’t really any differences. I do not want to share now the well known (you did know this, right)? sizing recommendation from Microsoft: Exchange 2013/2016 Sizing recommendation

I want to share the real numbers. For instance:
A Customer with 2360 Mailboxes is running Exchange 2013 on physical Hardware with 128GB RAM (hey  – wasn’t there the recommended limit with 96GB)? on a two node DAG.

Sometimes all databases are on one Server and the RAM Usage is on 101GB. The performance of Exchange is still perfectly – no reports for slow Outlook connections in Online mode or anything else.

Task-Manager

Another customer is using a virtualized environment with 64GB RAM for approx. 2200 users. Here we also do not see any issues with the size of RAM

So – just a hundred users less and running fine with 64GB.

Even if there are other recommendations – just check out the downscaling side of live. As long as there are no compliants from your users and Managed Availabilty is running fine (more on this in another post) everything is fine.

The only thing to keep in mind with RAM is: Do not run your Exchange 2013/2016 server with less than 7GB – otherwise you will need a lot of time for wating until tasks are done. Even my demo-environment runs on Windows Azure fine in that configuration (D2 VM)

Your EXGuru – aka Peter Forster – aka Satschent Peter