Deploy Extended Protection for Exchange server NOW

Exchange 2019 CU14 is expected to enable Windows Extended Protection in Exchange Server by default. This feature enhances the existing authentication in Windows Server and mitigates authentication relay or man-in-the-middle (MitM) attacks..

Extended Protection requires several very important prerequisites, which the link above describes.

Prerequisites for enabling Extended Protection on Exchange Server:

• SSL offloading must be disabled on all Exchange servers (it's enabled by default).

• Clients should use NTLMv2 instead of NTLMv1, which is the default setting in Windows. I recommend configuring this via Group Policy. If NTLMv1 is used by clients when Extended Protection is enabled, the configuration leads to password prompts on the client side without a way to authenticate successfully against the Exchange server.

• TLS configurations must be consistent across all Exchange servers within the organization. Any variation in TLS version use across servers can cause client connections to fail. I recommend that all Exchange servers be configured to use only TLS 1.2 for client and server operations, as well as .NET.

• Third-Party software running on your Exchange server must be compatible with Extended Protection. Ensure to test all third-party products that are running in your Exchange Server environment to ensure that they work properly when Extended Protection is enabled.

• Extended Protection doesn't work with hybrid servers using a Modern Hybrid configuration.

• Extended Protection can't be enabled on Exchange Server 2013 servers with Public Folders in a coexistence environment.

• Extended Protection can't be enabled on Exchange Server 2016 CU22 or Exchange Server 2019 CU11 or older that hosts a Public Folder hierarchy.

It's unlikely that the Exchange 2019 CU14 installer will perform "deep" inspection for these prerequisites, so this may cause problems in your environment if the prerequisites are not met and CU14 enables Extended Protection. The most likely issue will be that clients will be unable to connect or authenticate to Exchange server after Extended Protection is enabled.

I strongly recommend that all customers with Exchange server (including hybrid) check that they meet the requirements above and run the Exchange Extended Protection Management script before they install Exchange 2019 CU14. This script will check that the major requirements are met before enabling Extended Protection across all Exchange servers (not just Exchange 2019) in the organization.

The best course of action is to check and mitigate the Extended Protection prerequisites first. Always read the CU installation notes, especially if you use Windows Update to deploy this security update.

Please reach out to EXPTA Consulting if you would like assistance.

Read more ...

Do yourself a favor. Deploy PowerShell serialization for Exchange server NOW

Exchange 2019 CU12/13 Security Update 13 is expected to enable PowerShell serialization by default. This feature configures certificate-based signing of PowerShell serialization payloads to reduce the possibility of man-in-the-middle attacks in PowerShell scripts that connect to Exchange server.

PowerShell serialization requires prerequisites, which the link above describes:

Prerequisites to enable this feature: 

• Make sure that all Exchange-based servers in your environment have the January 2023 SU or a later SU installed. If you enable this feature before you update all servers, deserialization failures might occur and trigger other issues. 

• Make sure that a valid Exchange Server auth certificate is configured and available on all Exchange-based servers (except Edge Transport servers) before and after you enable certificate signing.

You can run the MonitorExchangeAuthCertificate.ps1 script to check for a valid auth certificate on Exchange-bases servers in your environment. The script also checks whether the auth certificate will expire in less than 60 days, and it can help you to rotate the certificate. For more information about MonitorExchangeAuthCertificate.ps1, see Monitor Exchange AuthCertificate

To manually check auth certificate availability and validity, see Auth Certificate Availability and Validity. 

We strongly recommend that you use the MonitorExchangeAuthCertificate.ps1 script (or create a new one, if it's necessary). This is because the script can also renew an expired auth certificate. The script includes a manual execution mode (verify the auth certificate availability or verify and take action, if it's necessary). The script also includes an automation mode that works by using Windows Task Scheduler.

It's unlikely that the SU installer will check for these prerequisites, so this may cause problems with Exchange scripts in your environment if the prerequisites are not met but the SU enables PowerShell serialization.

The best course of action is to check the prerequisites first, especially if you don't read the SU installation notes first or you use Windows Update to deploy this security update.

Read more ...

ProTip: Scheduled Task to Start Stopped Services in Exchange Server

As a best practice, I've always created a scheduled task on my Exchange Servers that starts all stopped services 1 minute after server startup. This is useful for virtualized environments where servers restart much faster than physical environments. Often the VM comes back up before the network has fully initialized. When this happens, some of the Exchange services do not start properly.

This scheduled task is becoming important with the release of the January 2023 Exchange Server Security Updates. There is a known issue that Microsoft Exchange AD Topology service may not start properly on Exchange 2016 servers running on Windows Server 2012 R2. Microsoft is investigating.

I've seen this happen on several of my customers' environments. Since almost all Exchange services rely on the AD Topology service, none of the Exchange services will start. You are required to start all the services manually after every reboot. Instead, you can install the scheduled task that does this for you.

Run the following from an elevated PowerShell or EMS prompt:

$TaskProgram =  "$env:SystemRoot\System32\WindowsPowerShell\v1.0\powershell.exe"

$TaskArguments = '-NoProfile -command "gwmi win32_service | where {$_.StartMode -eq ''Auto'' -and $_.State -eq ''Stopped''} | Start-Service"'

$TaskAction = New-ScheduledTaskAction -Execute $TaskProgram -Argument $TaskArguments

$TaskTrigger = New-ScheduledTaskTrigger -AtStartup -RandomDelay 00:01:00

Register-ScheduledTask -TaskName "Start Stopped Services" -Action $TaskAction -Trigger $TaskTrigger -RunLevel Highest -User "system" -Description "Starts all stopped services 1 minute after startup due to slow network initialization."

It's safe to install this on any Exchange server.

Read more ...

Bug when moving Public Folders to Exchange 2019

There's a bug in Exchange 2019 CU12 and earlier that causes New-MoveRequests for Public Folders to fail. 

The move request will fail with the error: StalledDueToMRS_Quarantined, which means that the Mailbox Replication Service (MRS) on the target Exchange 2019 server has crashed repeatedly due to the bug and has quarantined the move request (not the mailbox).

If you check the move request report with the Get-MoveRequestStatistics <PFMailbox> -IncludeReport | FL Report cmdlet you will see the error:

StatusDetail : StalledDueToMRS_Quarantined
Message : Request was quarantined because of following error: Object of type "Microsoft.Exchange.Data.Storage.PublicFolderSession" cannot be converted to object of type "Microsoft.Exchange.Data.Storage.MailboxSession"

or

InvalidCastExceptionException:
Unable to cast object of type 'Microsoft.Exchange.Data.Storage.PublicFolderSession' to type 'Microsoft.Exchange.Data.Storage.MailboxSession'

Microsoft is aware of the problem, which will be fixed in an upcoming Exchange 2019 Cumulative Update. It's unknown at this time if the fix will be included in Exchange Server 2019 CU13.

Read more ...

How to Setup Exchange Management Tools in Environments without Exchange Server

Some Exchange Online customers have an Active Directory on-premises, but never had Exchange Server on-prem. For example, customers who migrated their email from an Exchange hosted environment or from a different email system, such as Notes.

In some environments, these customers are having to manage user accounts and groups in both AD and Azure AD. This leads to confusion since accounts and passwords are not synced, so usernames and passwords can be different. Those customers may be looking for a way to master accounts, groups, and mailboxes from AD on-prem so they have a single source of authority, similar to the way that hybrid customers do.

In other environments, customers are using Azure AD Connect to sync users from AD on-premises to the cloud. Here, user accounts and groups are managed on-premises, but mailboxes are managed in Exchange Online. These customers may be looking for a way to manage mailboxes and groups from AD, so they also have a single source of authority.

The following steps will let you install the Exchange 2019 Exchange Management Tools (EMT) in an AD environment without having to install Exchange Server. 

Keep in mind that this solution is not supported by Microsoft, since manual configurations must be made in AD using ADSI Edit. The Microsoft supported way to do this is to install an Exchange Server in the org. The solution below does not require this.

Prerequisites

• Active Directory is installed and the Forest Functional Level is Windows Server 2012 R2 or higher.
• The Exchange Management Tools (EMT) must be installed on a domain-joined computer. Azure AD-joined by itself is not enough, since we need to be able to update Active Directory.
• EMT can be installed on Windows 10, Windows 11, or any Windows Server 2016+ server.
• You will need the Exchange Server 2019 CU12 or later media.
• The AD schema will be updated during EMT installation. These procedures assume the installation is being performed by a Domain Admin.

Steps for Installing the Exchange Management Tools

• Logon to the domain-joined computer or server where you want to install the EMT as a Domain Admin. For ease of installation, it is recommended that this computer be in the same AD site as the AD Schema Master.
• Install the .NET Framework 4.8.
• Install the Visual C++ 2012 Runtime.
• Install Windows Remote Server Administration Tools (RSAT) for Windows 10 or Windows 11. On Windows Server add the AD DS Tools from Server Manager.
• Install the IIS 6 Metabase Compatibility component using the following command:
• dism /online /Enable-Feature /FeatureName:IIS-IIS6ManagementCompatibility /all
• Restart the management computer twice to ensure all files and installations are up-to-date.
• Run Setup from the Exchange 2019 CU12+ media
• Select only Management Tools in the Server Role Selection
• You will be prompted to add the Exchange Organization Name (i.e., Contoso)
• Restart the computer after EMT installation
• Run the C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Add-PermissionForEMT.ps1 script from an elevated PowerShell prompt to create the Recipient Management EMT security group in the Users container.
• Add admin accounts to the new Recipient Management EMT group. Domain Admins already have rights to run the EMT and do not need to be added.
• Create a shortcut on the Desktop to the EMT:
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command "Add-PSSnapin *RecipientManagement"
• Configure the shortcut to run as Administrator

Note:

All mailbox management will be done using the EMT PowerShell cmdlets. The Exchange Management Shell (EMS) will also be installed, but you will never use it because you have no Exchange Server to connect to.

There is no built-in GUI for EMT recipient management, but fellow Office Apps & Services MVP Steve Goodman wrote one on GitHub. You may want to check it out. 

Also, be aware that the EMT does not support roles based access controls (RBAC) and there is no auditing available. For complete Microsoft EMT documentation see Install the Exchange management tools | Microsoft Learn.

Microsoft Exchange System Objects (MESO) Configuration

In order for admins to create remote mailboxes, you need to add a remote domain to the Exchange configuration partition in Active Directory. This is done using ADSI Edit. The usual disclaimer applies - Don't use this tool unless you know what you're doing. I accept no responsibility. Yada yada yada.

• Begin by getting your Microsoft 365 tenant's remote routing domain.
• Open Exchange Admin Center
• Navigate to Mail Flow > Accepted Domains
• Record the accepted domain of the domain that looks like domain.mail.onmicrosoft.com

• Open ADSIEdit.msc from the management computer. This was installed when you installed the Windows Remote Server Administration Tools (RSAT).
• Connect to the Configuration Naming Context.
• Navigate to CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=domain > CN=Global Settings > CN=Internet Message Formats
• Right-click CN=Internet Message Formats and select New > Object...
• Select the class msExchDomainContentConfig and click Next
• Enter Hybrid Domain - domain.mail.onmicrosoft.com for the value, using the value recorded above. Click Next and Finish.
• Edit the Hybrid Domain you just created and set the following values:
• contentType: 0
• domainName: domain.mail.onmicrosoft.com, using the value recorded above
• msExchContentByteEncoderTypeFor7BitCharsets: 15
• msExchContentPreferredInternetCodePageForShiftJis: 0
• msExchDomainContentConfigFlags: 1
• msExchMinAdminVersion: -2147453113
• msExchResolveP2: 2147483647
• msExchRoutingAcceptMessageType: 351
• msExchRoutingDisplaySenderEnabled: True
• msExchVersion: 4535486012416
• sendTNEF: True
• Close ADSI Edit.

Add the remote routing domain as an accepted domain.

• Run the following from an elevated EMT prompt, using the value you recorded above:
• New-AcceptedDomain domain.mail.onmicrosoft.com -DomainName domain.mail.onmicrosoft.com

Update the email address policy that was created when the EMT was installed.

• Run the following from an elevated EMT prompt:
• Get-EmailAddressPolicy | Set-EmailAddressPolicy -EnabledEmailAddressTemplates "SMTP:@domain.com","smtp:@domain.mail.onmicrosoft.com"
• Replace the domains with the correct values.
• SMTP:@domain.com (SMTP in all caps) is the primary SMTP address for your organization.
• smtp:@domain.mail.onmicrosoft.com is the remote routing domain that you recorded above.

Now you can run all the EMT cmdlets to update your on-prem user accounts, mailboxes, and groups.

Configure AD Synchronization with Azure AD

Now that you have a way to update Exchange attributes in AD, the final step is to configure Azure AD Connect to sync the AD objects with Azure AD. 

If your environment already has AAD Connect installed and configured, you only need to update the AAD Connect configuration to use Exchange Hybrid Deployment in Optional Features.

If your environment doesn't already have Azure AD Connect installed and configured, you will need to do so and perform a soft match of the AD accounts to Azure AD. That's beyond the scope of this article. 

If you need help please reach out to me at EXPTA Consulting.

Read more ...

Script to Set Exchange Server Antivirus Exclusions for Windows Defender

Microsoft released the June 2021 Quarterly Exchange Updates which now includes Exchange Server AMSI integration. 

The Antimalware Scan Interface (AMSI) allows antivirus software, such as Windows Defender which is installed by default on Windows Server 2016 and Windows Server 2019, to dynamically scan for malware such as the web shells created by the HAFNIUM attack earlier this year. Here's the Microsoft announcement which includes links to Exchange Server 2019 CU 10 and Exchange Server 2016 CU 21:

Exchange Server AMSI Integration

As mentioned in our recent blog post, the June 2021 CUs include new Exchange Server integration with AMSI (Antimalware Scan Interface). AMSI exists in Windows Server 2016 and Windows Server 2019, and the new integration is available in Exchange 2016 and Exchange 2019 when running on either of those operating systems. For Exchange 2016, AMSI integration is available only when running on Windows Server 2016. It is not available for Exchange 2016 running on Windows Server 2012 or Windows Server 2012 R2.

AMSI integration in Exchange Server provides the ability for an AMSI-capable antivirus/antimalware solution to scan content in HTTP requests sent to Exchange Server and block a malicious request before it is handled by Exchange Server. The scan is performed in real-time by any AMSI-capable antivirus/antimalware solution that runs on the Exchange server as the server begins to process the request. This provides automatic mitigation and protection that compliments the existing antimalware protection in Exchange Server to help make your Exchange servers more secure.

Because we know that some of our customers modify the web.config file on their Exchange Server, we wanted to let you know that installation of the June 2021 CUs will add a new section in the web.config of every HTTP service under <Modules>. The entry will be called "HttpRequestFilteringModule" and it must be present for AMSI integration to work.

AMSI helps keep your Exchange servers protected from malware, but it's still imperative to set the antivirus exclusions for Exchange Server as per the article, Running Windows antivirus software on Exchange servers on Microsoft Docs. This is required to prevent anti-virus/anti-malware solutions from potentially corrupting the Exchange Server installation, worker processes, and databases. Trust me. I've seen this happen many times and it usually ends up with a complete server rebuild.

If you've ever looked at this document, it lists many folder, process, and file name extension exclusions. To ease this configuration for Windows Defender I created the following Set-ExchangeAntivirusExclusionsForDefender.ps1 PowerShell script. 

Please note this script only works for Windows Defender running on Windows Server 2016 or 2019. If you're running another antivirus or antimalware solution, you'll still need to configure these exclusions some other way.

Simply copy the text below to a Set-ExchangeAntivirusExclusionsForDefender.ps1 file on your Exchange server and run it from EMS.

#Sets Exchange 2016/2019 antivirus exclusions for Windows Defender

#Author: Jeff Guillet | MCSM | MVP, jguillet@expta.com

#Ref: https://docs.microsoft.com/en-us/Exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2019

$m = Get-Module -ListAvailable Defender

if ($m -eq $null) {

Write-Host "Windows Defender is not installed on" (Get-WmiObject -class Win32_OperatingSystem).Caption

Exit

}

$ExchangeInstallPath = $Env:ExchangeInstallPath -replace ".$"

$excludedPaths = @( "$Env:SystemDrive\ExchangeSetupLogs", `

"$ExchangeInstallPath", `

"$Env:WinDir\SoftwareDistribution", `

"$Env:SystemRoot\Cluster", `

"$Env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files", `

"$Env:SystemRoot\System32\Inetsrv" ), `

"$Env:SystemDrive\inetpub\temp\IIS Temporary Compressed Files"

$excludedExtensions = @( "config", "chk", "edb", "jfm", "jrs", "log", "que", "dsc", "txt", "cfg", "grxml", "lzx" )

$excludedProcesses = @( "$ExchangeInstallPath\Bin\Search\Ceres\Runtime\1.0\noderunner.exe", `

"$ExchangeInstallPath\Bin\EdgeTransport.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.AntispamUpdateSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Diagnostics.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Directory.TopologyService.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.AntispamUpdateSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.EdgeCredentialSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.EdgeSyncSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Notifications.Broker.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.ProtectedServiceHost.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.RPCClientAccess.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Search.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Servicehost.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Store.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Store.Worker.exe", `

"$ExchangeInstallPath\Bin\MSExchangeCompliance.exe", `

"$ExchangeInstallPath\Bin\MSExchangeDagMgmt.exe", `

"$ExchangeInstallPath\Bin\MSExchangeDelivery.exe", `

"$ExchangeInstallPath\Bin\MSExchangeFrontendTransport.exe", `

"$ExchangeInstallPath\Bin\MSExchangeHMHost.exe", `

"$ExchangeInstallPath\Bin\MSExchangeHMWorker.exe", `

"$ExchangeInstallPath\Bin\MSExchangeMailboxAssistants.exe", `

"$ExchangeInstallPath\Bin\MSExchangeMailboxReplication.exe", `

"$ExchangeInstallPath\Bin\MSExchangeRepl.exe", `

"$ExchangeInstallPath\Bin\MSExchangeSubmission.exe", `

"$ExchangeInstallPath\Bin\MSExchangeTransport.exe", `

"$ExchangeInstallPath\Bin\MSExchangeTransportLogSearch.exe", `

"$ExchangeInstallPath\Bin\MSExchangeThrottling.exe", `

"$ExchangeInstallPath\Bin\OleConverter.exe", `

"$ExchangeInstallPath\Bin\UmService.exe", `

"$ExchangeInstallPath\Bin\UmWorkerProcess.exe", `

"$ExchangeInstallPath\Bin\wsbexchange.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\fms.exe", `

"$ExchangeInstallPath\Bin\Search\Ceres\HostController\hostcontrollerservice.exe", `

"$ExchangeInstallPath\TransportRoles\agents\Hygiene\Microsoft.Exchange.ContentFilter.Wrapper.exe", `

"$ExchangeInstallPath\FrontEnd\PopImap\Microsoft.Exchange.Imap4.exe", `

"$ExchangeInstallPath\ClientAccess\PopImap\Microsoft.Exchange.Imap4service.exe", `

"$ExchangeInstallPath\FrontEnd\PopImap\Microsoft.Exchange.Pop3.exe", `

"$ExchangeInstallPath\ClientAccess\PopImap\Microsoft.Exchange.Pop3service.exe", `

"$ExchangeInstallPath\FrontEnd\CallRouter\Microsoft.Exchange.UM.CallRouter.exe", `

"$ExchangeInstallPath\Bin\Search\Ceres\ParserServer\ParserServer.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\ScanEngineTest.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\ScanningProcess.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\UpdateService.exe", `

"$Env:SystemRoot\System32\Dsamain.exe", `

"$Env:SystemRoot\System32\inetsrv\inetinfo.exe", `

"$Env:Systemroot\System32\WindowsPowerShell\v1.0\Powershell.exe", `

"$Env:SystemRoot\System32\inetsrv\W3wp.exe" )

$excludedPaths | ForEach {if (!(Test-Path -Path $_ )) {New-Item -ItemType Directory -Path $_ }; Add-MpPreference -ExclusionPath $_ }

$excludedExtensions | ForEach {Add-MpPreference -ExclusionExtension $_ }

$excludedProcesses | ForEach {Add-MpPreference -ExclusionProcess $_ }

Be sure to run this from all your Exchange servers including those used for hybrid and Edge Transport after installation. You do not need to run it again after CU installations, but it won't hurt anything if you do.

Read more ...

Enable Outlook Automapping for Exchange mailboxes

When a user is delegated full access rights to another mailbox, automapping will automatically add that mailbox to that user's Outlook. Automapping does this when Outlook runs a background autodiscover process and discovers that the user has been given full access to another mailbox. The user doesn't need to add the mailbox manually to Outlook and will be unable to remove the additional mailbox.

Automapping is enabled by default, but it can be disabled by running the following cmdlet:

Add-MailboxPermission TeamMailbox -User kmeyer -AccessRights FullAccess -AutoMapping $false

The cmdlet above gives user Ken Meyer full access to the TeamMailbox mailbox and disables automapping for that mailbox.

I published the Enable-AutomappingForFullAccessMailboxes.ps1 script for Exchange in the Microsoft Script Center Gallery. The script re-enables Outlook automapping on mailboxes where users have been given full access rights. It runs on Exchange 2010-2019 and Exchange Online, and must be run from the Exchange Management Shell (EMS).

Read more ...

How to install Exchange Server 2019 on Windows Server 2019 Core Step-by-Step

The following article is a step by step walk-through for installing Exchange Server 2019 on Windows Server 2019 Server Core.

If you're looking for a super-fast and inexpensive lab server, check out my home lab server builds!

As announced, Exchange 2019 can be installed either on Windows Server 2019 with a GUI or Windows Server 2019 Core. Since Server Core lacks most GUI aspects, we need to use PowerShell and Remote Server Administration Tools (RSAT) to manage and administer Server Core. Here's how to install Windows Server 2019 Core and install Exchange Server 2019.

Install Windows Server 2019 Core:

You can download the Windows Server 2019 preview here.

Boot to the Windows Server 2019 Core ISO and run setup:

• Set Language, Time, and keyboard, Next
• Click Install Now
• Select the Operating System you want to install (Windows Server Standard or Windows Server Datacenter), Next
• Accept the license terms, Next
• Select Custom Installation
• Select the drive where you want to install Windows, Next. Windows will install and the server will restart.

The Administrator's password must be changed before signing in:

• Select OK to change it. 
• Enter the password twice to confirm and select OK again to sign in.
• Welcome to Server Core! Exciting, ain't it?

Run sconfig.cmd to configure the server (in this order):

• 2) Change Computer Name and restart. You must do this first if you're recovering an existing Exchange 2019 server.
• 8) Configure Network Settings (it's currently using DHCP). Set static IP, netmask, and default gateway. Then configure the DNS Servers.
• 7) Enable Remote Desktop (optional)
• 5) Configure Windows Update Settings (Automatic, DownloadOnly, or Manual)
• 6) Download and Install Updates
• 10) Configure Telemetry settings (optional)
• 1) Change Domain/Workgroup to join a domain. Restart.

Press Ctrl-Alt-Del to sign-in to the server with the Domain Admin account:

• Enter the username and password for the Domain Admin account

To enable file sharing so you can copy files to the new server, run the following from the CMD window:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

To enable the High Performance power configuration (recommended for Server Core VMs) run:

powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Now that Server Core on Windows Server 2019 is setup, we can install Exchange Server 2019.

Install Exchange Server 2019 on Windows Server 2019 Core:

You can download the Exchange Server 2019 Public Preview here.

Sign-in to Server Core with an account with Domain Admin, Enterprise Admin, and Schema Admin rights. If you're adding another server to an existing Exchange organization, you'll also need to be a member of Organization Administrators.

Mount the Exchange Server 2019 ISO. You can either mount it in your VM or copy the ISO to the new server and mount it in PowerShell by running the following cmdlet:

Mount-DiskImage -ImagePath "C:\Temp\ExchangeServer2019-x64.iso"

Change to the drive letter that represents the mounted ISO and run Setup to install most of the Exchange 2019 prerequisites:

Setup.EXE /Mode:Install /InstallWindowsComponents /IAcceptExchangeServerLicenseTerms /Roles:MB

Notice I said "most" of the prerequisites. The command above will install all the Windows Server roles and features, but Exchange 2019 still requires the Unified Communications Managed API (UCMA) runtime 4.0. You can't install UCMA until the Windows Server features are installed first. You may ask, "Why does Exchange 2019 still need UCMA even though Unified Messaging has been removed from the product?" The answer is, it's required for Lync and Skype for Business integration.

Setup will tell you to download UCMA 4.0 from a URL, but that setup won't work on Server Core. Instead, install the version included in the Exchange Server 2019 ISO in the UCMARedist folder.

Setup will also tell you to install the Visual C++ 2013 Redistributable Package from here. This one you'll have to download and install. I expect this will be included automatically by the time Exchange 2019 ships.

If you'd rather install the Windows prerequisites yourself from PowerShell instead of letting Setup do it, run the following cmdlet:

Install-WindowsFeature Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Http-Redirect,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Basic-Auth,Web-Client-Auth,Web-Digest-Auth,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Mgmt-Tools,Web-Mgmt-Compat,Web-Metabase,Web-WMI,Web-Mgmt-Service,NET-Framework-45-ASPNET,NET-WCF-HTTP-Activation45,NET-WCF-MSMQ-Activation45,NET-WCF-Pipe-Activation45,NET-WCF-TCP-Activation45,Server-Media-Foundation,MSMQ-Services,MSMQ-Server,RSAT-Feature-Tools,RSAT-Clustering,RSAT-Clustering-PowerShell,RSAT-Clustering-CmdInterface,RPC-over-HTTP-Proxy,WAS-Process-Model,WAS-Config-APIs

Now install the UCMA runtime and the Visual C++ 2013 Redistributable Package, then run Setup again. This time we don't need to specify installing the prerequisites:

Setup.EXE /Mode:Install /IAcceptExchangeServerLicenseTerms /Roles:MB

If you'd rather run Exchange Setup in the GUI mode, you can do that too and take advantage of the rebootless Windows component installation in Windows Server 2019 server core. Simply run Setup and let it install the prerequisites. Setup will halt because UCMA 4.0 and the Visual C++ 2013 Redistributable Package are not installed - install them. Then click Retry in Exchange Setup and it will continue on with the installation. Awesome!

Once setup completes, restart the server and you can continue to configure the server using the Exchange Management Shell or the Exchange Admin Center from another PC.

Post-Setup Tips:

Run the LaunchEMS cmdlet from a CMD prompt to launch the Exchange Management Shell in another window locally on the server.

If you're new to Windows Server Core, read Manage a Server Core Server for basics on server administration.

I highly recommend Windows Admin Center (formerly Project Honolulu) for managing Server Core servers, or any other Windows server for that matter. It allows you to perform most all server tasks from a single browser window, including updating device drivers. Pretty cool!

Good luck with your Exchange 2019 Server Core implementations! If you need help with your deployments, please reach out to EXPTA Consulting.

Read more ...

Cross-Premises Mailbox Delegation in Hybrid Office 365

Exchange hybrid organizations commonly ask about delegating mailbox permissions between on-premises and cloud users. I'm happy to say that this is finally becoming a reality. This is being rolled out to all Office 365 tenants by the end of April 2018.

Gone are the days when you had to migrate users with delegated permissions at the same time to keep delegation working when migrating to Exchange Online. To enable cross premises delegation you first need to configure it in Exchange on-premises EMS with the following cmdlet:

Set-OrganizationConfig -ACLableSyncedObjectEnabled $true

This is all you need to allow an on-prem user to become a delegate of a cloud user's mailbox.

If you want to allow a cloud user to become a delegate of an on-prem user, you need to reconfigure the msExchRecipientDisplayType attribute for the remote user in on-prem AD. This will allow the cloud user's mailbox to become ACLable. The default value on-prem for a mailbox that has been migrated to Exchange Online is -2147483642. This value must be changed to -1073741818.

The following on-prem cmdlet will change the value for a particular mailbox:

Get-ADUser user@contoso.com -Properties msExchRecipientDisplayType | where {$_.msExchRecipientDisplayType -eq -2147483642} | Set-ADUser -Replace @{msExchRecipientDisplayType = -1073741818}

And this cmdlet will change the value for all migrated mailboxes:

Get-ADUser -Filter * -Properties msExchRecipientDisplayType | where {$_.msExchRecipientDisplayType -eq -2147483642} | Set-ADUser -Replace @{msExchRecipientDisplayType = -1073741818}

Once this is done, the cloud users can become a delegate for on-prem users. Note that there is no need to force directory replication using AAD Connect. It just works. Note that it may take up to two hours before Office 365 recognizes the change.

Here's how this looks in Outlook. First, I'll show how it looks before I run the cmdlets.

Begin by clicking File in Outlook and then Account Settings > Delegate Access. This will open the Delegates dialog box.

Remote user is not ACLable

Click Add to open the Add Users window. Notice that my Jeff Guillet account has a red circle with a line through it. That means my mailbox is not ACLable. If I try to delegate to that mailbox I get the error, "The user cannot be added. Non-local users cannot be given rights on this server."

After I run the cmdlets above, I follow the same steps. Now my Jeff Guillet user account can be added for delegation.

Remote user is now ACLable.

I can now configure the level of delegation and optionally send the delegate an email summarizing these permissions.

For details on Full Access, Send-As, and Send-On-Behalf-Of permissions in a hybrid environment, please read Overview of delegation in an Office 365 hybrid environment.

Read more ...

Storing email signatures in the Exchange mailbox

UPDATE: On Sept. 10 I received notice that this UserVoice item will be implemented in the near future. See Syncing Email Signatures Across Devices is soon to become a reality!!

A common complaint is that users must configure their email signatures every time they configure their mailbox on a new Outlook client or in OWA for the first time.

The current email signature behavior in Exchange and Exchange Online is that users must create new signatures every time they add a new mailbox in Outlook and in each of the Outlook apps. OWA already stores a text and HTML signature in the mailbox, but Outlook doesn't use it. OWA also does not provide for different signatures or a different reply signature like Outlook does. That's very inconsistent behavior.

In a recent discussion with the Exchange and Outlook product groups, the MVPs discussed a long-standing request - to store email signatures in the user's mailbox. Doing so will provide a centralized place to store and retrieve the signatures and provide consistency for the email clients that consume them (Outlook for desktop, Outlook on the web (OWA), and the Outlook apps (iOS and Android)). We are also requesting that signatures can be managed via PowerShell.

The product groups challenged us to show that customers want this by vote count on UserVoice. Please vote for the "Store Signatures in the mailbox" idea on UserVoice website to make your voice heard. I've written a spec for this feature, which I will be submitting to the PGs once the vote count gets higher. Our expectation is that this will work for both Exchange Server and Exchange Online.

Please up-vote this feature request and let's see if we can get this one done!

Read more ...

Announcing AAD Connect 1.1.749.0 with new privacy and troubleshooting features

Microsoft is drizzling out a new build of Azure Active Directory Connect via auto-upgrade to select customers. They often do this when a new build has significant changes to make sure it doesn't break in existing organizations that currently use AAD Connect. It will be available for all customers to download in the coming days/weeks as either an auto-upgrade or manual download.

The new version includes new privacy and troubleshooting features that were previously unavailable. The new privacy features are especially important for customers for customers affected by GDPR. Head on over to the Enow ESE Blog to read more and understand how these new features can help your business...

Read more ...

Wash the "unclean". Fixing mailbox enabled cloud-only user accounts in Office 365 for hybrid migrations.

I've come across the following scenario in a number of migration projects. The customer creates a new tenant with or without AAD Connect with the intention of "kicking the tires" in Office 365. They create several cloud-only accounts and assign them licenses. Since these cloud-only accounts don't have an ExchangeGUID tying them back to on-prem Exchange, they are given a new mailbox in Exchange Online.

Later, the customer decides to perform a hybrid migration of all or some mailboxes to EXO. AAD Connect is configured with the Exchange Hybrid setting and Azure AD is able to "soft-match" the cloud users to the on-prem user accounts. Now we have the same user object with two mailboxes, one on-premises and the other in the cloud. This is bad. Mail flow will be affected and we will be unable to migrate the user mailbox to EXO because a mailbox already exists. To fix it, we need to delete the cloud mailbox so that Exchange hybrid can create a new (empty) mailbox to migrate to when we're ready.

If we unlicense the user in Office 365 it will soft-delete the cloud mailbox, but when we license it again Office 365 will automatically reconnect the soft-deleted mailbox back to the user account. It does this because the PreviousRecipientTypeDetails property on user account is set to "UserMailbox". When this property is set, the user account is "unclean" and Exchange Online will always want to reconnect the soft-deleted mailbox. Even if we manage to permanently delete the cloud mailbox, EXO will create another new cloud mailbox when the user is re-licensed.

Previously, the only way to correct this was to permanently delete the cloud user account using Remove-MsolUser and Remove-MsolUser -RemoveFromRecycleBin remote PowerShell cmdlets, and then sync the object back from on-prem AD. The problem with this is that it's cumbersome to do and, more importantly, also deletes any prior SharePoint and OneDrive data that the cloud user may have accumulated.

A normal synced user in a hybrid scenario before migration to EXO

In the coming days, Microsoft is rolling out a new switch for the the Set-User remote PS cmdlet which addresses this issue. Running Set-User -PermanentlyClearPreviousMailboxInfo in remote PowerShell will clear the PreviousRecipientTypeDetails property and return the user account to a "clean" condition. This will prevent EXO from creating a cloud mailbox, as shown above. The new command disconnects the cloud mailbox without affecting other data stored in Office 365, such as SharePoint or OneDrive data.

Note that this will permanently delete the cloud mailbox, so you should have the user save any important emails first or export the mailbox to a PST.

Read more ...

Secure AAD Connect! New build 1.1.654.0 and AdSyncConfig.psm1 module is available

If you attended my webinar yesterday on "Exchange Hybrid for the Long Haul - Critical Information to Know" you learned how important it is to keep AAD Connect up-to-date.

Yesterday Microsoft released AAD Connect build 1.1.654.0 which addresses a security vulnerability that allows lower level administrators to gain elevated privileges by resetting the password of the on-prem MSOL_xxxxxx account used by AAD Connect for synchronization. To be honest, this is no more risky than allowing junior admins from resetting the password of any highly privileged account or being able to add themselves to a highly privileged group, like Domain or Enterprise Admins. You should always secure and monitor any highly privileged account or group in your organization.

The AAD Connect Version History explains the security issue that build 1.1.654.0 addresses. It also gets the EXPTA award for the most poorly written release notes ever. Spelling errors, grammar errors, syntax errors, oh my. But I digress...

Microsoft also released a PowerShell script (module, really), AdSyncConfig.psm1, which configures the new recommended permissions on the MSOL_xxxxxx account for those organizations who need to secure the account immediately, but can't upgrade to the latest version of AAD Connect at this time. The script is available on the TechNet Gallery.

The AdSyncConfig module is not quite as straight forward as written, though, so I wanted to document here how to use it. The first problem is that the module is not digitally signed. That means that you'll get the warning, "The publisher of AdSyncConfig.psm1 couldn't be verified" when you download it with Internet Explorer. Edge doesn't complain.

It also means that you will probably have to change your execution policy in PowerShell to run it. The recommended execution policy of RemoteSigned will prevent the module from being imported since it's not digitally signed.

If you can't upgrade to the latest build immediately, here are all the correct steps to use the AdSyncConfig.psm1 module to secure the MSOL_xxxxxx account immediately. There is no downtime associated with these steps.

• Download AdSyncConfig.psm1 to your AAD Connect computer and open an elevated PowerShell console.
• Run Get-ExecutionPolicy to view the current policy. Usually it's RemoteSigned or Restricted.
• Run Set-ExecutionPolicy -ExecutionPolicy Unrestricted in order to import the unsigned module.
• Run Import-Module AdSyncConfig.psm1 to import the module.
• Run $Account = Get-ADUser -Filter 'Name -like "msol_*"' to store the account information for the MSOL_xxxxxx account.
• Run Set-ADSyncRestrictedPermissions -ObjectDN $Account.DistinguishedName -Credential (Get-Credential) to reset the permissions on the MSOL account to the new recommended settings. Be sure to use domain\username format. 
• Run Set-ExecutionPolicy -ExecutionPolicy RemoteSigned to reset the execution policy.
• Run Restart-Service adsync to restart the Microsoft Azure AD Sync service.
• Run Start-ADSyncSyncCycle -PolicyType Delta to force a new delta sync and confirm that synchronization is working properly.

Once you install AAD Connect build 1.1.654.0 or run the steps for the module above, you will see that the MSOL_xxxxxx account has updated permissions for SELF.

Read more ...

How to Change the PowerShell Prompt as Default in Windows 10 Creators Update

You may notice that when you right-click the Windows start button or press Windows key-X to pull up the taskbar menu that the Command Prompt and Command Prompt (Admin) options have been replaced with Windows PowerShell and Windows PowerShell (Admin) options. I know it's a little thing and don't get me wrong, I love PowerShell, but sometimes I'd rather normally open an elevated CMD prompt.

If you want to change this back to the pre-Creators Update behavior simply open Settings and click Personalization. Then click the Taskbar settings.

Turn off, Replace Command Prompt with Windows PowerShell in the menu when I right-click the start button or press Windows key-X. This was the default behavior before the Creators Update.

Read more ...

How to Self-Elevate a PowerShell Script

Update: I updated the code below so it works correctly when there are spaces in the path or script name. Thanks to Pat Richard for performance and deprecation improvements.

Most of the scripts I write require elevation -- they must be run from an elevated PowerShell prompt because they make changes to Windows that require Administrator access. The following code snippet will self-elevate a PowerShell script with this added to the beginning of the script. I honestly can't remember where I found the original code, but I updated it to work with Windows 10 and Windows Server 2016 and later build numbers.

Of course, you should ALWAYS confirm that your script is running properly before allowing it to self-elevate. I take no responsibility for the scripts that run using this code.

# Self-elevate the script if required
if (-Not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {
if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) {
$CommandLine = "-File `"" + $MyInvocation.MyCommand.Path + "`" " + $MyInvocation.UnboundArguments
Start-Process -FilePath PowerShell.exe -Verb Runas -ArgumentList $CommandLine
Exit
}
}

Simply add this snippet at the beginning of a script that requires elevation to run properly. It works by starting a new elevated PowerShell window and then re-executes the script in this new window, if necessary. If User Account Control (UAC) is enabled, you will get a UAC prompt. If the script is already running in an elevated PowerShell session or UAC is disabled, the script will run normally. This code also allows you to right-click the script in File Explorer and select "Run with PowerShell".

Here's how it works:

• The first line checks to see if the script is already running in an elevated environment. This would occur if PowerShell is running as Administrator or UAC is disabled. If it is, the script will continue to run normally in that process.

• The second line checks to see if the Windows operating system build number is 6000 (Windows Vista) or greater. Earlier builds did not support Run As elevation.

• The third line retrieves the command line used to run the original script, including any arguments.

• Finally, the fourth line starts a new elevated PowerShell process where the script runs again. Once the script terminates, the elevated PowerShell window closes.

Pretty slick!

Read more ...

How to Uninstall Antispam Agents on Exchange Servers

UPDATE: The Exchange Team posted an article about this issue today. See Exchange Server Edge Support on Windows Server 2016 Update.

Microsoft announced that they were deprecating support for the SmartScreen spam content filter for Exchange Server in September 2016. See the article, Deprecating support for SmartScreen in Outlook and Exchange for full details.

All that is supposed to mean is that Microsoft is no longer producing anti-spam signatures for Exchange, but I discovered today that the Microsoft Exchange Transport service would not start on my Exchange 2016 Edge Transport servers after a servicing reboot. These Edge servers are running on Windows Server 2016. The Application event log shows the following error:

Log Name:      Application
Source:        MSExchangeTransport
Date:          3/17/2017 2:59:07 PM
Event ID:      16023
Task Category: Configuration
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mail.contoso.com
Description:
Microsoft Exchange couldn't start transport agents. The Microsoft Exchange Transport service will be stopped. Exception details: Failed to create type 'Microsoft.Exchange.Transport.Agent.ContentFilter.ContentFilterAgentFactory' from assembly 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\Hygiene\Microsoft.Exchange.Transport.Agent.Hygiene.dll' due to error 'Exception from HRESULT: 0xC0630005'...

The highlighted section in the error log indicates the problem is with the content filter, which is one of the antispam agents installed with the Install-AntispamAgents.ps1 PowerShell script. Whenever the MSExchangeTransport service is started, the service stops again within a minute and this event is logged.

The fix for me is to remove the content filter transport agent on the Exchange server(s) where the antispam agents are installed. Run the Get-TransportAgent cmdlet from the Exchange Management Shell to see if the antispam agents are installed. These transport agents include the Content Filter Agent, Sender Filter Agent, Sender ID Agent, and Protocol Analysis Agent.

To uninstall these agents use the Uninstall-TransportAgent cmdlet. For example,

Uninstall-TransportAgent -Identity "Content Filter Agent"
Uninstall-TransportAgent -Identity "Sender Id Agent"
Uninstall-TransportAgent -Identity "Content Filter Agent"
Uninstall-TransportAgent -Identity "Protocol Analysis Agent"

For me, all I really needed to uninstall as the Content Filter Agent to get the Transport Service to start.

Once you've uninstalled them you need to restart the Transport Service:

Restart-Service MSExchangeTransport

This will start the Microsoft Exchange Transport Service if it was already stopped and you're back in business. Of course, you still need a good antispam service for on-prem. I use Exchange Online Protection (EOP) which works very well for me and most of my customers.

Read more ...

How to Trigger an AAD Connect Sync from a Remote Computer

If you use AAD Connect to synchronize on-premises Active Directory with Azure AD, you may find it more convenient to trigger an AAD sync from a remote domain-joined computer or server. I frequently do this when I make a change to an on-prem AD object from my Windows 10 workstation or Exchange server. Remote PowerShell to the rescue!

Copy the following Sync-AAD.ps1 script to your Windows path (I put it in C:\Windows) on the computer or server where you want to run it.

$AADComputer = ((Get-ADUser -Filter 'Name -like "AAD_*"' -Properties Description).Description).split(" ")[13].trim(".") + "." + (Get-WmiObject win32_computersystem).Domain
$session = New-PSSession -ComputerName $AADComputer
Invoke-Command -Session $session -ScriptBlock {Import-Module -Name 'ADSync'}
Invoke-Command -Session $session -ScriptBlock {Start-ADSyncSyncCycle -PolicyType Delta}
Remove-PSSession $session

Sync-AAD.ps1 output

I haven't found a better way to determine where AAD Connect is installed than the way I'm doing it in the first line. It uses the AD PowerShell module to parse out the AAD Connect computer name listed in the description property of the AAD_***** computer account. This assumes, of course, that the AD PowerShell module is installed on the local computer, and the description property is filled out correctly in AD. AAD Connect sets the description for this account to something like, "Service account for the Synchronization Service with installation identifier 16e45891... running on computer DC1." If that doesn't work for you for some reason, simply change the first line to your AAD computer FQDN, for example:

$AADComputer = "aad.contoso.com"

The second line, $session = New-PSSession -ComputerName $AADComputer,creates a new remote PowerShell connection to the computer where AAD Connect is installed.

The third line invokes a command to import the AAD Connect PowerShell module on the local computer.

The fourth line invokes a command to start the delta AD sync cycle.

The final line removes the remote PowerShell session.

Easy peasy!

Read more ...

Fix for Performance Counter Updating Error (Event 106) on Exchange Servers

You may see multiple warnings or errors in the Application event log on Exchange servers for event 106, indicating that performance counters could not be updated.

Multiple Event ID 106 - Perf Counter Events

An example event 106 reads,

Log Name:      Application
Source:        MSExchange Common
Date:          11/29/2016 12:24:28 PM
Event ID:      106
Task Category: General
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EX16B.contoso.com
Description:
Performance counter updating error. Counter name is Percentage of Failed Offline GLS Requests in Last Minute, category name is MSExchange Global Locator OfflineGLS Processes. Optional code: 3. Exception: System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.
   at System.Diagnostics.PerformanceCounter.InitializeImpl()
   at System.Diagnostics.PerformanceCounter.get_RawValue()
   at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.set_RawValue(Int64 value)

The TechNet article, "'Performance counter updating error' after you install an Exchange Server 2013 cumulative update", indicates this is a problem on Exchange 2013 after applying a CU, but I've seen this happen after applying an update rollup, cumulative update, or .NET Framework update on Exchange 2010, Exchange 2013, or Exchange 2016 servers.

I wrote the following PowerShell script to reload the Exchange performance counters. You run it directly on the affected Exchange server from an elevated PowerShell or EMS prompt. The script will reload all the performance counters in the %ExchangeInstallPath%\setup\perf directory.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup
$perfcounters = Get-ChildItem "$env:ExchangeInstallPath\Setup\Perf\" *.xml | Where-Object {!($_.psiscontainer)}
$perfcount = $perfcounters.Count

foreach ($perfcounter in $perfcounters) {
New-PerfCounters -DefinitionFileName $perfcounter.FullName -ErrorAction SilentlyContinue
Write-Progress -Activity "Reloading $perfcount Exchange Performance Counters" -PercentComplete (($i++ / $perfcount) * 100)}

The script may take a few minutes to run and will reload all the Exchange performance counters. Once complete, the event 106 warnings or errors should stop.

Read more ...

New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

Set-AutodiscoverSCP.ps1

I just published version 2.0 of my Set-Autodiscover.ps1 script to the TechNet Gallery. This is a complete rewrite of the old script and includes the following new features:

• Made setting the new values easier by cloning an existing server
• Now also configures Outlook Anywhere and all Exchange virtual directory internal and external URLs
• Revised verbiage and use *-ClientAccessService cmdlets for Exchange 2016
• Added -Verbose output to display the values we're configuring
• Improved overall display output

These changes are intended to make the script more powerful and easier to use.

---

How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured in Active Directory when the Front-End Client Access role is installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the self-signed Exchange certificate installed by setup is not trusted. If the new server is Internet-facing, ActiveSync clients can also get security warnings on their mobile device.

Read Exchange Active Directory Deployment Site for more information about this behavior.

I wrote a script, Set-AutodiscoverSCP.ps1 (available on the TechNet Gallery), that automatically updates the SCP, Outlook Anywhere FQDNs, and all the virtual directory internal/external URLs for the server your specify to match the values currently configured on another server you specify as soon as the new server is detected in AD. It continually polls Active Directory until it finds the new SCP value and sets the new values. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:

Set-AutodiscoverSCP.ps1 [-Server] <String> [-ServerToClone] <String> [[-DomainController] <String>] [<CommonParameters>]

Two examples of usage:

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01

Example #1 continually queries the current configuration domain controller until it finds an SCP for server EXCH02 and then sets it to match the SCP of EXCH01. It also configures Outlook Anywhere and the internal/external virtual directory URLs to match those found on EXCH01.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01 -DomainController dc03

Example #2 is almost the same as the command in the previous example, except it continually queries DC03 for the SCP record and configures it on that domain controller. This is useful when configuring a new Exchange server in a different Active Directory site.

The script is designed to be run during installation. Normally, you would run this script from an existing Exchange server of the same version while the new server is being installed.

You can also run the script directly from the server that is being installed. This is useful when you're installing the first Exchange 2013/2016 server in a 2010 environment. You can start running the script on the new server when the Client Access Front End Service is being installed. The caveat is that setup restarts IIS and web services several times during setup, causing the script to possibly stall during configuration of the virtual directories. If that happens, simply CTRL-C to quit the script and run it again.

I've included error handling for the following conditions:

1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
2. The script checks that the server, server to clone, and the domain controller (if specified) are pingable. If the servers cannot be pinged, the script will terminate.
3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script again on the TechNet Gallery as needed.

Read more ...