A quick blog on the recent release of .NET Framework 4.7.2. In the past I blogged about the tight relationship between Exchange versions and the .NET Framework, and the supported combinations of those two to deploy and run Exchange. Shortly after publishing that article, Microsoft revised its support statement:
“When upgrading Exchange from an unsupported CU to the current CU and no intermediate CUs are available, you should upgrade to the latest version of .NET that’s supported by Exchange first and then immediately upgrade to the current CU. This method doesn’t replace the need to keep your Exchange servers up to date and on the latest, supported, CU. Microsoft makes no claim that an upgrade failure will not occur using this method, which may result in the need to contact Microsoft Support Services”.
Now while 4.7.2 is a minor release, it is not mentioned in the Exchange supportability matrix at this moment. As such, it is not a validated combination, and you will be in uncharted territory with an unsupported configuration. The revised support statement only mentions upgrading Cumulative Update directly to a recent release as many customers were faced with a two-step upgrade process coming from old Cumulative Updates, basically ignore the supportability matrix. However, it does not mention anything about upgrading to the latest .NET Framework version at this moment. So don’t.
To block (accidental) installation of .NET Framework 4.7.2, you can configure the following registry key on your current Exchange servers to block its installation:
Coming back from a nice vacation to the beautiful Brittany in France, I thought it was time to collect and process feedback and suggestions on several scripts, starting with the Exchange 2013 unattended installation script for Windows Server 2012.
Changes in version 1.1 of the script:
When the script was used to also prepare Active Directory, RSAT-ADDS-Tools was uninstalled as part of the cleanup. Per request, I’ve removed the uninstallation of that feature;
The script now detects pending reboots after installing the required features. When ran in AutoPilot mode, the script will reboot and restart the phase (preparing Active Directory, which can’t be run with pending reboots because Exchange’s Setup won’t like it). When not running in AutoPilot mode, you need to start the script manually. You can omit providing installation parameters as they are saved, even a pending is detected;
The Windows feature Server-Media-Foundation will be installed explicitly as it is an UCMA 4.0 requirement;
The credentials provided for AutoPilot mode will be validated;
The OS version check is changed to a string which should enable installation on non-US Operating Systems.
I’m pleased to announce the availability of Install-Exchange15.ps1, a PowerShell script to perform a fully automated unattended setup of Exchange Server 2013, Exchange Server 2016 or Exchange Server 2019 (Desktop and Core) is supported).
The script takes care of:
Installing requires Windows Server features
Install Exchange Server prerequisites, e.g. .NET Framework 4.5.2/4.6.1/4.6.2/4.7.1/4.7.2/4.8 and Visual C++ Runtime 2012 or 2013, depending on roles, OS and Exchange version to install.
Install additional prerequisites and prepare Active Directory.
Optionally install Exchange Server 2013 / 2016 / 2019.
Optionally, install required fixes and perform post configuration, like setting your Power Plan to High Performance, reconfiguring the pagefile to best practices (memory + 10MB with a maximum of 32GB+10MB) if it is system managed, and performing .NET framework optimizations. Custom post-configuration is possible by modifying the script.
On Windows Server 2016 and later, it will configure Windows Defender exclusions when present.
For Exchange 2016 CU22 and Exchange 2019 CU11 and later, will install the required URL Rewrite 2 module.
Finally, the script will clean things up, like removing the state file and setting the startup of Transport Service back to Automatic.
Usage This script version requires a domain-joined Windows Server, an account to perform the installation (and optionally prepare Active Directory) and the location where the Exchange Server 2013/2016/2019 installation files are stored (e.g. an UNC path).
Organization (optional): Specifies name of the Exchange organization to create. When omitted, the step to prepare Active Directory (PrepareAD) will be skipped.
InstallMailbox: Specifies you want to install the Mailbox server role. Applies to Exchange 2013 as well as Exchange 2016.
InstallCAS: Specifies you want to install the CAS role. Applies to Exchange 2013 only, ignored when installing Exchange 2016.
InstallMultiRole:Specifies you want to install both Mailbox server and CAS roles. Applies to Exchange 2013 only.
InstallEdge: Specifies to install the Edge Transport rule (Exchange 2013/2016).
MDBName (optional): Specifies name of the initially created database.
MDBDBPath (optional): Specifies database path of the initially created database (requires MDBName).
MDBLogPath (optional): Specifies log path of the initially created database (requires MDBName).
InstallPath (optional): Specifies (temporary) location of where to locate – and when downloaded store – prerequisite files, the state file and log files. Default location is C:\Install. You can also use a UNC path to use a central location, given the credentials have sufficient permissions to write at this location. This is ideal when you want the script to use previously downloaded hotfix files, for example, as some required hotfixes are quite large (e.g. KB3206632 for WS2016 ~ 1GB, KB2919355 for WS2012R2 ~ 700MB).
NoSetup (optional): Specifies you only want to install prerequisites (and optionally prepare the Exchange organization), Exchange setup and post-configuration steps are not performed. You still need to specify SourcePath because the Exchange version will determine the prerequisites to install.
Recover: Specifies you want to install this server in Recovery mode. The script will check if an Exchange server object is already defined.
SourcePath: Specifies location of the Exchange 2013 installation files. This can point to the location of setup.exe, or the location of the ISO.
TargetPath: Specifies the location where to install the Exchange 2013.
AutoPilot (switch): Specifies you want to automatically restart, logon using credentials specified and continue the installation. When not specified, you will need to restart, logon and start the script manually each time (without parameters).
Credentials (optional): Specifies credentials to use for automatic logon. Use DOMAIN\User or user@domain. When not specified, you will be prompted to enter credentials.
IncludeFixes (optional). Depending on operating system and detected Exchange version to install, will download and install recommended hotfixes.
SCP (optional) allows you to reconfigure the Service Connection Point record for Autodiscover after Exchange setup has finished. Specify the full URI, e.g. https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Use ‘-‘ to clear the SCP entries of the server.
Lock (optional) locks the system when running script.
NoNet48 (optional) to use .NET Framework 4.7.2, even when installing an Exchange version which is supported with .NET Framework 4.8.
NoNET471 (optional) to use .NET Framework 4.6.2, even when installing an Exchange version which is supported with .NET Framework 4.7.1.
NoNET472 (optional) to use .NET Framework 4.7.1, even when installing an Exchange version which is supported with .NET Framework 4.7.2.
NoNET461 (optional) to use .NET Framework 4.5.2, even when installing an Exchange version which is supported with .NET Framework 4.6.1 or higher.
DisableSSL3 (optional) to disable SSL3 protocol as per KB187498.
DisableRC4 (optional) to disable RC4 cipher as per KB2868725.
SkipRolesCheck (optional) to bypass membership checks for Schema Admin and Enterprise Admin roles.
EdgeDNSSuffix specifies the DNS suffix to configure on the primary NIC.
Note that the script uses an XML file to store the (original) parameters used to start the script but also to keep track of the the process. Of course, if required, you can use predefined XML files to run the script without parameters.
Note that when not present, the script will try to download the prerequisites from the internet. When that isn’t possible or to save bandwidth, you can put them in the location defined by InstallPath and the script will detect and use them.
The post-configuration is currently adding IFilters for OneNote and Publisher (Mailbox) only. There are comments in the script where to add your own additional post-configuration steps.
For example, assume we want to start a fully unattended install of an Exchange Server 2013 Client Access server, using a network location for the Exchange Server 2013 source files. After setting the Execution Policy to Unrestricted and storing the script locally, we start the script using:
The script will perform some checks and since AutoPilot was specified without using the Credentials parameter, the script will ask for credentials.
After entering the credentials, the required features will be installed. Since OrganizationName wasn’t specified, Active Directory preparation will be skipped.
After rebooting, the system will automatically log on using the credentials specified earlier and start the script (RunOnce registry key is utilized for this purpose). It will read the last known state from the XML file and will continue with the next phase, which is downloading (when not present) and installing the Exchange prerequisites.
Next, after rebooting and the automatic logon, Exchange will be installed from the source location.
When done, the system will perform post configuration and finalization steps.
When running in AutoPilot mode, the system will automatically perform reboots and logons between the steps. Note that it may seem like a lot of reboots, but rebooting after installing Windows features and Exchange prerequisites is required anyway so I put reboots after the other milestones as well.
Customization If you want to perform post-setup configuration of Exchange running Exchange cmdlets from the script, you need to tailor it to your needs. Locate the line which reads:
#Load-ExchangeModule
Uncomment this line so a proper Exchange Management Shell session will be set up to the local Exchange server. You can insert Exchange-related cmdlets after the Load-ExchangeModule line to configure your server. Be advised that you need to port modifications to new versions of the installation script.
Recovery The script also supports recovery mode (/mode:RecoverServer). After checking the Exchange server object is present in Active Directory, installation will proceed as normal, with the exception of running setup in recovery mode. For example:
Update The script also supports update mode (/mode:Update). After checking the Exchange server object is present in Active Directory, and checking for presence of Exchange installation, installation will proceed as normal, with the exception of running setup in Update mode.
Feedback Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.
Download You can download Install-Exchange15.ps1 from TechNet or GitHub.
Note: This article is based on a pre-release product and may therefor be subject to changes.
Yesterday, the Exchange team released the preview (you can also call this a public beta) of Microsoft Exchange Server 2013. The build version of the Exchange 2013 Preview is 15.0.466.10.
You can download the 1,5GB self-extracting Exchange 2013 Preview here.
Prior to installing Exchange 2013 preview, you need to install the following prerequisites depending on the targeted platform
Note: Clicking the checkmark leads to the download.
Component
Windows Server
2008 R2 SP1
Windows Server
2012
.NET Framework 4.5 RC
Windows Management Framework 3.0 RC
UCMA 4.0 Preview
Office 2010 Filter Pack (Mbx)
Office 2010 Filter Pack SP1 (Mbx)
Windows Identity Foundation (KB974405)
KB2619234
KB2533623
Note: When present, uninstall the Visual C++ 11 Beta Redistributable after installing the UCMA component. On Windows Server 2008 R2 SP1 you also need to register ASP.NET after uninstalling the VC++ 11 Beta Redistributable, before installing Exchange 2013, using:
%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable
followed by an IISReset.
Required Windows Features These cmdlets install the required Windows features:
Firewall
On Windows Server 2012, create an inbound firewall rule for port 139 when installing Client Access server.
Active Directory Requirements Be advised that a minimum of 1 Windows Server 2008 Domain Controller and Global Catalog server is required in each site where you want to install Exchange 2013 Preview. Windows Server 2003 Forest Level is supported.
After successfully preparing Active Directory for Exchange 2013, the schema version will be 15132, Forest version 15448 and the Domain version 13236. More information on how to verify those values here.
To quickly check the level of your domain controllers, you can use the script provided here which will report the msDS-Behavior-Version attribute (3 = 2008).
Order of things Microsoft recommends you install Mailbox servers before installing Client Access servers.
IPv6 Like Exchange 2010, Exchange 2013 supports IPv6. However, a pure IPv6 environment isn’t supported, so IPv4 is still required.
Co-Existence Everybody who’s still running on Exchange 2003 (many customers are) need to follow an intermediate upgrade path when moving to Exchange 2013 when it goes RTM, as co-existence between Exchange 2013 and Exchange Server 2003 isn’t supported. Note that the preview version isn’t supported in co-existence with any Exchange version by the way.
Release Notes
Be sure to also check out the Release Notes here.
When setting up Exchange, by default setup assumes the domain controller it talks to is up to date and replication is working almost instantly. Unfortunately, depending on your Active Directory configuration and replication scheme, this isn’t always guaranteed. In such cases, issues can arise of which one I would like to show below.
Note that the problem mentioned due to replication latency may also occur when running cmdlets or scripts.
A typical issue caused by replication lag is the following error which is shown when trying to install the Mailbox server role:
Active Directory operation failed on dc01.contoso.com. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1: 0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200ab (homeMTA)
In the Exchange setup log you can notice something like the following pattern (in this case setup takes place from a sub domain):
[04/18/2012 09:59:15.0328] [2] Active Directory session settings for 'Enable-Mailbox' are: View Entire Forest: 'True', Configuration Domain Controller: 'dc01.nl.contoso.com', Preferred Global Catalog: 'dc01.nl.contoso.com', Preferred Domain Controllers: '{ dc01.nl.contoso.com }' <snip> [04/18/2012 09:59:36.0945] [1] 0. ErrorRecord: Active Directory operation failed on dc01.contoso.com. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers.
You can see the Domain Controller used for updating Active Directory is different than the one used for checking. Assuming replication is working correctly, you have several options to get around the situation, depending on whether you’re running setup or executing a cmdlet or script:
First, when running setup, you can use the /DomainController parameter to specify a Domain Controller setup should use, e.g.:
Alternatively, when running a cmdlet or script you can configure the Domain Controller to use by using Set-ADServerSettings in conjunction with the PreferredServer parameter, e.g.
Of course, there’s also a 3rd option which would be to wait for replication cycle. However, this could take a while, depending on the structure and replication scheme.
Note that the (potential) problem mentioned in this blog is the reason why you should let scripts stick to the same Domain Controller after picking one or respect the Set-ADServerSettings setting, preventing potential replication issues like this.
For more information on Set-ADServerSettings, consult TechNet here.
When setting up federation between Exchange organization using the Hybrid Configuration Wizard, to connect your on-premise Exchange environment with Office 365, you may encounter an error message in the 2nd step of the Hybrid Configuration Wizard, Update-HybridConfiguration:
When inspecting the Update-HybridConfiguration results, it reads:
Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.
Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.
Federation information could not be received from the external organization.
..
The problem lies in the sentence “Federation Information could not be received from external organization”. To see where it goes wrong, you could run Set-HybridConfiguration and Update-HybridConfiguration manually, using additional parameters as shown in the result screen, providing proper credentials and additionally addint the Verbose parameter to increase output logged.
Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where example.com is to be replaced by the federated domain:
Get-FederationInformation example.com –Verbose
You’ll probably see the cmdlet going trough the discovery motions using autodiscover, ending up in the same “Federation information could not be received from the external organization” message. When analyzing this output, you’ll see it contains two hints on the potential issues:
Get-FederationInformation : The discovery process returned the following results:
Type=Failure;Url=https://autodiscover.example.com/autodiscover/autodiscover.svc;Exception=Discovery for domain example.com failed.; …
1. Autodiscover The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. split DNS configurations. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside.
Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. However, federation will use DNS records so you need allow it or set it up in DNS; a CNAME for autodiscover.example.com as well as autodiscover.service.example.com pointing to your hybrid server will suffice.
Also make sure you enable WSSecurity authentication for autodiscover on your hybrid server using:
Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true
2. Proxy rules In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. Issue is, these service requests require unauthenticated traffic. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied.
To solve this issue, and to get federation working, you need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths:
/EWS/Exchange.asmx/wssecurity
/Autodiscover/Autodiscover.svc
/Autodiscover/Autodiscover.svc/wssecurity
After configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.
After applying the rule changes, Get-FederationInfo example.com should work and you can continue with the Hybrid Configuration.
Something which I still see many Administrators do, right after installing Exchange 2010, is renaming the mailbox database or relocating the database or logs files that were created during the setup of Exchange 2010.
To configure the initial mailbox database name, the location of the initial mailbox database (and catalog) files or its log files, you can incorporate the following parameters in your setup command line:
MdbName is the name of the initially created mailbox database, e.g. MDB01
DbFilePath is the full path of the initially created mailbox database file, e.g. E:\MDB01DB\MDB01.edb
LogFolderPath is the folder used to store the database log files, e.g. D:\MDB01LOG
Note that you must use the complete filename of the edb file, including the .edb extension. Also, you don’t need to create the folders; Exchange will do that for you during setup.
So, to setup Exchange with a custom initial mailbox database name and non-default locations of database and log files, you can use the following command line for example:
Today I encountered a strange issue when trying to decommission a DAG member, after properly removing it from the DAG as explained here, and checking services like address book generation server where hosted on one of the other DAG members.
I started the removal process from an elevated command prompt (using the GUI doesn’t work as it complains about the need to use setup.com, which I can’t since I’m using the GUI):
setup /m:uninstall
The output was the following:
Hmm. Without even looking at the Exchange setup log, I noticed there was something strange with the error message:
The term ‘C:\Program Files\Microsoft\Exchange Server\V14\Bin\ManageScheduledTask.ps1’ is not recognized as the name of a cmdlet, function, script file, or operable program.
As you probably know, all Exchange scripts are located in the Scripts folder, not the Bin folder.
I tried a quick and dirty fix, which was to copy the ManageScheduledTask.ps1 and ManageScheduledTask.strings files to the Bin folder, and again started setup /m:uninstall. This time, Exchange uninstalled nicely.
From experience, this isn’t expected behavior, but in case you encounter this problem in the field, you now know how you can easily work around this.
Update: I’ve seen identical issues when retrying an upgrade on Exchange 2010 SP1 to SP2. I think the problem is code-related (i.e. bug), as the uninstall part of the upgrade process should check for those files in “scripts”, not “bin”. Note that with case of the failing SP2 upgrade, the file EnterpriseServiceEndpoints.xml was also MIA (that one should be in bin). I worked around that by copying the file from the installation source.
Right after launching Office 365, Microsoft released Service Pack 1 for Microsoft Office 2010 (KB2460049) which includes Office 365 support besides a big list of fixes. For those interested, Office 2010 SP1 can be downloaded here (x86) and here (x64). For a full list of changes, check out Microsoft Office 2010 Service Pack 1 Changes Excel sheet.
More interesting for Exchange folks is that there’s also an SP1 for the Microsoft Office Filter Pack 2010, which of course you install during Exchange setup as one of the prerequisites. As you probably know, the Filter Pack is used to index Office documents stored in Exchange databases to speed up queries.
You can download Service Pack 1 for Microsoft Office Filter Pack 2010 x64 Edition here. The related knowledgebase article is KB2460041.
With the arrival of Service Pack 1 for Windows Server 2008 R2, Dynamic Memory was introduced. In brief, Dynamic Memory is a memory management enhancement for Hyper-V which allows running virtual machines (VM) to allocate memory from the host and releasing it when possible, giving a minimum and maximum memory boundary. The main benefit is a higher VM density, because each VM will only allocate what’s required and you don’t have to approximate memory allocations.
Now this mechanism works well for many applications, but not for Exchange. Exchange’s goal – at least that of servers holding the mailbox role – is to claim as much memory as possible in order to cache information. This amount depends on the installed of memory (more information here). This cache is used for performance reasons, more cache means less I/O’s, less I/O’s result in better performance. You can guess what happens when you run Exchange with a minimal amount of memory and lots of dynamic memory configured, optionally shared with other Dynamic Memory-enabled VM’s. If Exchange starts up and wants to claim memory for caching or allocate memory for other reasons (transactions), instead of the memory being available instantly the host first needs to allocate it, or worse have other VM’s surrendering it their memory. That doesn’t make sense and will result in significant performance penalty.
Besides it being pointless to configure Dynamic Memory for Exchange, it’s also not recommended. From the Exchange 2010 System Requirements:
Many of the performance gains in recent versions of Exchange, especially those related to reduction in I/O, are based on highly efficient usage of large amounts of memory. When that memory is no longer available, the expected performance of the system can’t be achieved. For this reason, memory oversubscription or dynamic adjustment of virtual machine memory should be disabled for production Exchange servers.
Applications that perform their own memory management by taking over certain aspects of memory management from the operating system. Such applications typically grab as much memory as they possibly can in order to ensure the application’s best performance which can cause the amount of memory allocated to their virtual machine to grow until it reaches the amount specified by the Maximum RAM setting;
Applications where memory allocation is a one shot operation that is performed either when the application starts for the first time or each time the application starts.
Concluding, yes you can use Dynamic Memory for your lab or testing environment and it works. But don’t use it in production for Exchange Server.
Credits to Jetze who blogged about this originally here (Dutch).
A quick blog on the recent release of .NET Framework 4.7.2. In the past I blogged about the tight relationship between Exchange versions and the .NET Framework, and the supported combinations of those two to deploy and run Exchange. Shortly after publishing that article, Microsoft revised its support statement:
EighTwOne (821) 