Outlook Web App (OWA) HTTP to HTTPS Redirection

For most companies today, we want to make access to OWA easy for the users. Most folks will just type in mail.domain.com/owa or something of the like to get to the OWA page. If you don’t use HTTPS by default though, you will not be able to access OWA and will get an error on the page. We need to be able to redirect the HTTP query to go to SSL or HTTPS so that you get the proper logon page and have the access secured by SSL PKI as per the security standard.
Now, most bigger companies will install a load balancer that will program the redirection to HTTPS when the request is made before it hits the Exchange Server. But, for small companies, like mine, that cannot afford a load balancer, we need a native way in Windows and Exchange to be able to perform the same task and have it redirect to HTTPS so that your users are not confused when typing in the address.

The following shows how to configure IIS so that it natively redirects all HTTP requests for OWA to HTTPS.

By default in Exchange Server, the URL https://<ServerName> redirects users to https://<ServerName>/owa. But, if anyone tries to access Outlook on the web (formerly known as Outlook Web App) by using http://<ServerName> or http://<ServerName>/owa, they’ll get an error.

You can configure http redirection for Outlook on the web so that requests for http://<ServerName> or http://<ServerName>/owa are automatically redirected to https://<ServerName>/owa. This requires the following configuration steps in Internet Information Services (IIS):

  1. Remove the Require SSL setting from the default website.
  2. Restore the Require SSL setting on other virtual directories in the default website that had it enabled by default (except for /owa).
  3. Configure the default website to redirect http requests to the /owa virtual directory.
  4. Remove http redirection from all virtual directories in the default website (including /owa).
  5. Reset IIS for the changes to take effect.

Step 1: Use IIS Manager to remove the Require SSL setting from the default website

  1. Open IIS Manager on the Exchange server. An easy way to do this in Windows Server 2012 or later is to press Windows key + Q, type inetmgr, and select Internet Information Services (IIS) Manager in the results.
  2. Expand the server, and expand Sites.
  3. Select Default Web Site. and verify Features View is selected at the bottom of the page.
  4. In the IIS section, double-click SSL Settings.
    SSL1
  5. On the SSL Settings page, clear the Require SSL check box, and in the Actions pane, click Apply.
    SSL2

Note: To perform this procedure on the command line, open an elevated command prompt on the Exchange server (a Command Prompt window you open by selecting Run as administrator) and run the following command:

Step 2: Use IIS Manager to restore the Require SSL setting on other virtual directories in the default website

When you change the Require SSL setting on a website in IIS, the setting is automatically inherited by all virtual directories in the website. Because we’re only interested in configuring Outlook on the web, you need to restore the Require SSL setting for other virtual directories that had it enabled by default.

Based on the information in the Default Require SSL and HTTP Redirect settings in the default website on an Exchange server section, use the following procedure to restore the setting on the other virtual directories where Require SSL was enabled by default:

  1. In IIS Manager, expand the server, expand Sites, and expand Default Web Site.
  2. Select the virtual directory, and verify Features View is selected at the bottom of the page.
  3. In the IIS section, double-click SSL Settings.
    SSL3
  4. On the SSL Settings page, select the Require SSL check box, and in the Actions pane, click Apply.
    SSL4
  5. Repeat the previous steps on each virtual directory in the default website that had Require SSL enabled by default ***(except for /owa)***. The only virtual directories that don’t have Require SSL enabled by default are /PowerShell and /Rpc.

NOTE: PLEASE REMEMBER TO NOT CHECK THE “Require SSL” FOR THE /OWA DIRECTORY. THIS WILL CAUSE A 403 Access Denied ERROR WHEN TRYING TO REDIRECT.

Note: To perform these procedures on the command line, replace <VirtualDirectory> with the name of the virtual directory, and run the following command in an elevated command prompt:

Step 3: Use IIS Manager to configure the default website to redirect to the /owa virtual directory.

  1. In IIS Manager, expand the server, and expand Sites.
  2. Select Default Web Site. and verify Features View is selected at the bottom of the page.
  3. In the IIS section, double-click HTTP Redirect.

  4. On the HTTP Redirect page, configure the following settings:
  5. Select the Redirect requests to this destination check box, and enter the value /owa.
  6. In the Redirect Behavior section, select the Only redirect requests to content in this directory (not subdirectories) check box.
  7. In the Status code list, verify Found (302) is selected.When you’re finished, click Apply in the Actions pane.

Note: To perform this procedure on the command line, open an elevated command prompt and run the following command:

Step 4: Use IIS Manager to remove http redirection from all virtual directories in the default website

When you enable redirection on a website in IIS, the setting is automatically inherited by all virtual directories in the website. Because we’re only interested in configuring redirection for the default website, you need to remove the redirect setting from all virtual directories. By default, no directories or virtual directories in the default website are enabled for redirection. For more information, see the Default Require SSL and HTTP Redirect settings in the default website on an Exchange server section.

Use the following procedure to remove the redirect setting from all virtual directories in the default website (including /owa):

  1. In IIS Manager, expand the server, expand Sites, and expand Default Web Site.
  2. Select the virtual directory, and verify Features View is selected at the bottom of the page.
  3. In the IIS section, double-click HTTP Redirect.

  4. On the HTTP Redirect page, change the following settings:
  5. Clear the Only redirect requests to content in this directory (not subdirectories) check box.
  6. Clear the Redirect requests to this destination check box.
  7. In the Actions pane, click Apply.

  8. Repeat the previous steps on each virtual directory in the default website.

Note: To perform these procedures on the command line, replace <VirtualDirectory> with the name of the virtual directory, and run the following command in an elevated command prompt:

Step 5: Use IIS Manager to restart IIS

  1. In IIS Manager, select the server.
  2. In the Actions pane, click Restart.

Note: You can also perform an IISRESET from and Elevated PowerShell Prompt.

My biggest take away from this was NOT setting the SSL Requirement Properly in the /owa directory when configuring this. By default, the setting is to Require SSL, but to redirect properly, you have to have that Virtual Directory in IIS set to NOT Require SSL. Having the 403 error was driving me crazy. I had to get someone else to look at it, but they didn’t catch it either! That is why I made a point to write this article with the /owa catch in mind. I hope this helps!

HAPPY CONFIGURATION!
POSITIVE LIFE WILL BRING SUCCESS!

REFERENCES:
Configure http to https redirection for Outlook on the web in Exchange Server
Default Require SSL and HTTP Redirect settings in the default website on an Exchange server

Exchange 2010 Extended Support will end on October 13th, 2020

I wanted to pass this announcement along to everyone so that they are aware of the support ending for Exchange 2010. I personally have noticed a large number of Exchange 2010 environments starting to show age as the newer Outlook clients are having performance issues with Exchange 2010. If your team has not planned an upgrade to Exchange 2016 (you cannot upgrade directly from Exchange 2010 to 2019), I would advise that your team do so very soon. Exchange 2010 has been a great product for many years, but it is finally time for it to retire and allow the next generation of Messaging Services take the stage.

Formal Announcement:

Exchange 2010 End of Support extended to October 2020

Announced today, and in alignment with Office 2010 and SharePoint 2010, and after investigating and analyzing the deployment state of an extensive number of Exchange customers, Microsoft has decided to move Extended Support date for Exchange Server 2010 from January 14th 2020 to October 13th 2020.
After October 13th 2020, Microsoft will no longer provide technical support for problems that may occur with Exchange 2010 including:

– bug fixes for issues that are discovered and that may impact the stability and usability of the server
– security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
– and time zone updates

Customer installations of Exchange 2010 will, of course, continue to run after this date; however, due to the changes and potential end of support risks, Microsoft strongly recommends customers migrate from Exchange 2010 as soon as possible.

FAQ’s

  • Can customers upgrade directly to Exchange 2019?
    Customers cannot upgrade directly from Exchange 2010 on-premises to Exchange Server 2019. They may upgrade to Exchange 2013 or 2016 directly from Exchange 2010 and we of course recommend Exchange 2016.
  • Since Exchange 2010 runs on Server 2008 and 2008R2, are those operating systems still supported?
    On January 14, 2020, support for Windows Server 2008 and 2008 R2 will end. That means the end of regular security updates for these Windows customers. Since Exchange Server 2010 runs on top of Windows Server 2008 and Windows Server 2008 R2, it’s important for customers to consider how they will obtain security updates for the underlying operating system. Extended Security Updates for Server 2008 and 2008 R2 are now available for purchase and can be ordered from Microsoft or a Microsoft licensing partner. The delivery of Extended Security Updates (ESU) will begin after the End of Support dates, if and when available. 
  • Does Microsoft support Exchange 2010 on any other Server versions?
    Exchange Server 2010 SP3, with Update Rollup 26 or higher, installed on Windows Server 2012 R2 is supported until October 13, 2020.
  • That didn’t quite answer my question. If a customer calls between January 14 and October 13 2020, and is running Exchange 2010 on Server 2008 or 2008 R2, and does not have an ESU for Windows, can they still be assisted?
    Yes. Per the Lifecycle FAQ.
    If I am running a Microsoft product that is currently supported under the Lifecycle Policy, but my operating system is no longer supported, can I still receive support?
    If the problem is specific to the Microsoft product and it is within the Lifecycle Policy, Microsoft will provide support.
    If the problem is a result of the combination of the operating system and the Microsoft product, the problem will not be supported.
    More simply::
    Exchange 2010 on Server 2008 or 2008 R2: Starting January 14, 2020, provide support until a proven issue is found with the OS. This ends in October 2020.
    Exchange 2010 SP3 RU26+ on Server 2012 R2: We support regardless, but Exchange support still ends in October 2020.

  • Will Microsoft be offering Extended Support Updates (ESU’s) for purchase for Exchange 2010 customers?
    No.
  • What resources are available for customers? 
    – An upcoming Exchange Team blog post, titled “Exchange On-Premises Best Practices for Migrations from 2010 to 2016,” will provide great technical guidance for customers and support agents with their on-premises migrations.  
    – If migrating to Office 365 and Exchange Online, customers may be eligible to use the free Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make migration to Office 365 and Exchange Online as seamless as possible.
    – For customers that run into any problems during their migration to Office 365 and are not eligible for FastTrack, or if migrating to a newer version of Exchange Server, customers can of course utilize Support or the Exchange Technical Community.
    – Customers may also choose to engage a partner to help.  Microsoft has a great number of partners with deep skills in Exchange, and you can browse a list of Exchange partners at
    https://www.microsoft.com/en-us/solution-providers/home.

HAPPY UPGRADING!
CONTACT ME FOR QUESTIONS CONCERNING UPGRADING YOUR EXCHANGE ENVIRONMENT!

Exchange Server Client Access URL Configuration Script

In my career, I have to be able to be efficient as most of my projects are on a time crunch schedule. Being able to quickly configure Exchange when setting up a server environment is crucial to the success of the project.

While still honing my skills in PowerShell, I was attempting to create my own script to help configure all of the Virtual Directories in one shot rather than go to each setting and configure them manually. It did not go very well, so as I do, I research and find great professionals that do great work in scripting so that I may learn from them.

In doing so, I found Paul Cunningham’s script that performs this. I took the following script and modified it to add the PowerShell Virtual Directory to it as I like to configure that as well.

***YOU CAN REM THE LINES OUT SHOULD YOU NOT WANT TO CONFIGURE THAT DIRECTORY***

Here is my version of the script:

NOTES:

  • PowerShell script to configure the Client Access server URLs for Microsoft Exchange Server 2013/2016. All Client Access server URLs will be set to the same namespace.
  • If you are using separate namespaces for each CAS service this script will not handle that.
  • The script sets Outlook Anywhere to use NTLM with SSL required by default.
  • If you have different auth requirements for Outlook Anywhere use the optional parameters to set those.
  • The script sets PowerShell to use Basic with SSL required by default.
  • If you have different authentication requirements for PowerShell use the optional parameters to set those.
  • PowerShell was added to the settings. Please be sure to REM those lines of code should you NOT want to configure the PowerShell Virtual Directory.

USAGE:

HAPPY SCRIPTING!
POSITIVE ENERGY!
PLEASE COMMENT!

REFERENCES:
Exchange Server Client Access URL Configuration Script
PowerShell Script to Configure Exchange Server Client Access URLs

Installing an ‘IP-less’ Exchange Server 2019 Database Availability Group

Yesterday, I posted on how Exchange now uses the Resilient File System (ReFS) to optimize and protect Exchange critical files. Another layer of protection is using a database availability group (DAG) for redundancy and is a necessary factor when designing an Exchange Enterprise Environment.
In this example, I will walk you through the installation of an Exchange Server 2019 DAG as I configured in my environment. This DAG will contain two Exchange Servers in the same site with a third Windows Server 2019 server being the File Share Witness (FSW).

Two Server Exchange DAG Configuration

For my configuration, I configured two identical Windows Server 2019 VMs (same procs, RAM, vhdx drives, partitions, etc…). I configured the Exchange Data Volume using ReFS and mounted them to the same folder on the C: Drive on each server. This is very important for replication to take place successfully when the databases are added to the DAG.


I next went to the Admin server where the FSW would be hosted and added the Exchange Trusted Subsystem Account to the local Administrators group on that server:

IMPORTANT!
Add the Exchange Trusted Subsystem Account to the Local Administrators Group on the FSW.

NOTE: The reason that this is an ‘IP-less’ DAG is that I’m creating a DAG with no cluster administrative access point (CAAP). The DAG has no IP address of its own, and no computer object in Active Directory. The main implication of this is that backup software that relies on the CAAP or backup operations won’t work. This option of an ‘IP-less’ DAG was first introduced in Exchange Server 2013 SP1/CU4, so by now any decent backup products should support this configuration. But you should always verify this with your backup vendor of choice. Also be aware that this is only supported for DAGs that are running on Windows Server 2012 R2 (or later).

Next, we create the DAG from Exchange PowerShell using the New-DatabaseAvailabilityGroup cmdlet. Now remember that since you are using the ReFS system for your database volumes, you will need to specify the -FileSystem parameter within the cmdlet to assure proper setup and replication of the data files.

Next, we add the Exchange Servers that hold the databases that will be replicated within the DAG:

The DAG will now show the two servers as Operational Member Servers:

The FSW Directory was created on the admin01 server when the DAG was created. We can verify that with the following cmdlet:

Next, we add the databases that we want replicated to the DAG as replicated databases. I want all my Databases on EX01 to replicate to EX02 and vice versa for the EX02 Databases. I want the activation preference to remain on the server that the databases were originally created on so I will use the -ActivationPreference parameter to accomplish that. I will go into more detail on Activation Preference in another post.

Now we verify that the Database Copies are healthy on each replication member using the Get-MailboxDatabaseCopyStatus cmdlet. You will see a Healthy Status on the replicated copies:

POSITIVE ENERGY!
KILL NARCISSISM!
HAPPY TROUBLESHOOTING!

REFERENCES:
Installing an Exchange Server 2016 Database Availability Group

Using the Resilient File System for Exchange Server

In my ongoing effort for becoming more knowledgeable on Exchange Server, I found that the preferred new file system for Exchange Databases and Log files is the ReFS.
ReFS is not that new. Microsoft’s Resilient File System (ReFS) was introduced with Windows Server 2012. ReFS is not a direct replacement for NTFS, and is missing some underlying NTFS features, but is designed to be (as the name suggests) a more resilient file system for extremely large amounts of data.

Support for ReFS with Exchange Server

From Exchange Server 2013 and upwards (which includes Exchange Server 2019 today) Microsoft supports the use of ReFS for Exchange servers, and in fact they now recommend it as the preferred file system for Exchange Server 2019, within the following guidelines.

For Exchange Server 2013:

  • ReFS is supported for volumes containing Exchange database files, log files, and content index files.
  • ReFS is not supported for volumes containing Exchange binaries (the program files).
  • ReFS is not supported for volumes containing the system partition.
  • ReFS data integrity features must be disabled for the database (.edb) files or the entire volume that hosts database files.
  • Hotfix KB2853418 must be installed.
  • For Windows 2012, the following hotfixes must be installed:

This means that you should continue to use NTFS for your operating system and Exchange Server 2013 installation volume, but you can consider using ReFS for the volumes hosting Exchange databases, log files, and index files.

For Exchange Server 2016:

  • ReFS is supported for volumes containing Exchange database files, log files, and content index files.
  • ReFS is not supported for volumes containing Exchange binaries (the program files).
  • ReFS is not supported for volumes containing the system partition.
  • ReFS data integrity features are recommended to be disabled.
  • For Windows 2012, the following hotfixes must be installed:

This means that you should continue to use NTFS for your operating system and Exchange Server 2016 installation volume, and it is recommended ReFS for the volumes hosting Exchange databases, log files, and index files.

For Exchange Server 2019:

  • ReFS is supported for volumes containing Exchange database files, log files, and content index files.
  • ReFS is not supported for volumes containing Exchange binaries (the program files).
  • ReFS is not supported for volumes containing the system partition.
  • ReFS data integrity features are recommended to be disabled.

This means that you should continue to use NTFS for your operating system and Exchange Server 2019 installation volume, and it is recommended ReFS for the volumes hosting Exchange databases, log files, and index files.

Creating an ReFS Formatted Volume

In Windows Server during the New Volume Wizard when you get to the step for configuring File System Settings change the file system from NTFS to ReFS.

exchange-server-refs

NOTE: Using the New Volume Wizard does not give you the option to disable data integrity at the volume level. To set it at the volume level itself use PowerShell when configuring new volumes. I found this out the hard way and am now re-configuring my volumes to disable the Integrity Streams.

I needed to create the mount point to mount the volume to:

I then got a list of my available disks:

In my case, disk 2 was the one I needed to format and change. I had to create a new partition and then format it:

Once formatted, I mount the volume to the Directory created earlier:

NOTE: Partition 1 on a disk is always reserved for system files on the drive volume. So the active partitions will always start at 2.

Lastly, verify that the partition is online and that the Integrity Streams are turned off:

Additional Considerations

When you are deploying an Exchange 2016 or 2019 DAG and using Autoreseed, the disk reclaimer needs to know which file system to use when formatting spare disks. So when, creating a DAG in Exchange PowerShell, make sure to set the -FileSystem parameter. For Exchange Server 2013 DAGs, manually format the spare volumes with ReFS.

More coming soon. I will post how I setup the “IP-less” DAG for my environment and got replication functional for my Exchange Databases.

REFERENCES:
Exchange 2013 storage configuration options
Exchange 2016 Preferred Architecture
Exchange Storage for Insiders: It’s ESE (Ignite video)
ReFS Exchange Server Volumes
Preparing ReFS Volumes for Exchange

Set the profile pic for a single Exchange user via PowerShell

I wanted to update my picture within my Outlook profile and AD account really quickly without having to go through OWA to do so. I found this cmdlet that will allow for that picture to be changed very quickly via Exchange PowerShell.

NOTE: This can be done with On-Premises Exchange and Exchange Online PowerShell

Old picture within my account

First, download the picture you want to use to the computer that you want to run the cmdlet from. Also, make sure the picture is cropped and centered prior to running the cmdlet. I saved the pic to C:\temp for my scenario. The best format to use would be jpg. I named the file User1_Profile.jpg

Next, open Exchange PowerShell on the computer you saved the pic to and run the following cmdlet to change the photo:

Once completed, the Outlook client should be closed and reopen so that the new picture is visible in the profile.

Picture change completed

I will post how to perform this for multiple users for Exchange and Office365 in a later post.

REFERENCES:
Set User Photo with Exchange PowerShell

Purging Soft Deleted mailboxes from Exchange Server

If you’re a seasoned administrator, you have knowledge that in Exchange, the database settings will allow you to set the deleted mailbox retention. The default is 30 days, but sometimes you need to purge all those deleted mailboxes to do some ‘spring cleaning’ as it were. Note that doing these cmdlets does not change the ‘Whitespace’ of the database or the size. In my case, I had to purge everything of a toxic individual that was tainting my network much to my disappointment and did the following to complete that task.

The following cmdlet will seek all Soft Deleted mailboxes within the database you select and manually purge them from Exchange.

Now, should you only want to remove one mailbox, you will need to get the GUID of that Soft Deleted mailbox first so that you can enter it for the identity parameter.

You can also preform a similar task for a disabled mailbox:

You can perform the task on all disabled mailboxes for that database as well:

NOTE: I would be very careful when performing either of these cmdlets as they will completely purge the mailboxes from the schema. If these cmdlets assist you with your ‘spring cleaning’, I will have been happy to assist.

HAPPY PURGING!
PLEASE COMMENT!
IGNORANCE IS NOT BLISS!

References:
Purging Deleted Mailboxes on Exchange 2013

Server Monkey
LDLNET LLC’s Preferred Server Equipment Hardware Vendor

Customize your Outlook Web App Logon Page

As many of you are aware, Microsoft provides a default logon page for OWA, the Outlook Web App. Most companies, like myself want to be able to customize that page so that it suites your organization. Here is what my company OWA page looks like:

Customized OWA Logon Page

I have changed the color on the left to match my scheme, replaced the Outlook Logo with my company logo, and added a disclaimer to notify users. Below is the process to do that effectively for your organization.

NOTE: Every time you install an Exchange Cumulative Update (CU) or new version of Exchange Server these modified files will be replaced. Remember to backup your original and changed files to another folder so that you can replace them when you Update or Upgrade or if something goes wrong with the changes.

Customize the color of the Outlook on the web sign-in page

  • Use Notepad to open the file:

%ExchangeInstallPath%FrontEnd\HttpProxy\owa\auth\<ExchangeVersion>\themes\resources\logon.css

  • In the logon.css file, replace the default blue hexidecimal color value #0072c6 with the HTML RGB value that you want to use. You can use the following LINK to choose the color you wish to use.
  • When you’re finished, save and close the file.

Here are the different graphics that can be changed on the OWA logon page and their associated files:

Outlook on the Web sign-in page with element call-outs
ImageFile nameLocationDimensions (width x height in pixels)Bit depth

favicon.ico 
%ExchangeInstallPath%FrontEnd\HttpProxy\owa\auth\<ExchangeVersion>\themes\resources
16 x 16 
32 

olk_logo_white.png 
%ExchangeInstallPath%FrontEnd\HttpProxy\owa\auth\<ExchangeVersion>\themes\resources
128 x 108 
32 

owa_text_blue.png 
%ExchangeInstallPath%FrontEnd\HttpProxy\owa\auth\<ExchangeVersion>\themes\resources
300 x 76 
32 

Sign_in_arrow.png (for left-to-right languages) 
Sign_in_arrow_rtl.png (for right-to-left languages) 
%ExchangeInstallPath%FrontEnd\HttpProxy\owa\auth\<ExchangeVersion>\themes\resources
22 x 22 
32 
  • Just resize your images to the given dimensions in the table, rename them to the file name, and replace the files in the directory.

Change the disclaimer text for your OWA logon page

Next, we want to add a disclaimer to our logon page. To do that, we need to modify the logon.aspx document in the following directory:

%ExchangeInstallPath%FrontEnd\HttpProxy\owa\auth\logon.aspx

Open the file in Notepad or your favorite HTML editor and search for the text ‘hidden-submit’. When you find the text, you can add your disclaimer text under the div class=”disclaimer” tag as I did in the following example:

Save your logon.aspx file and give your OWA server an IISRESET for good measure. You should be good to logon with the new page from that point on.

HAPPY CONFIGURING!
PLEASE COMMENT!
THANKS FOR YOUR SUPPORT!

References:
Customize the Outlook on the web sign-in, language selection, and error pages in Exchange Server
CUSTOMIZE EXCHANGE 2016 OUTLOOK ON THE WEB SIGN IN PAGE
Customizing Exchange 2016 OWA

Exchange Hybrid Configuration Wizard Link

Wanted to do a quick post as I was working on my Hybrid Exchange Environment. I was unable to get the HCW to download and start from the Exchange Control Panel with the link provided on the page. This has happened to me for a while, so I went online and found a link that would work that could be downloaded and reused to open the HCW:

Hybrid Configuration Wizard Link

HOPE THIS HELPS!
LET ME HAVE KNOWLEDGE SHOULD THE LINK CHANGE!

References:
HYBRID CONFIGURATION WIZARD WON’T START ON WINDOWS 2016

Exchange Setup Repeatedly Says ‘A Restart from a Previous Installation is Pending’

I have had this issue with EVERY upgrade that I have ever attempted for Exchange Server from 2013 through 2019 CU1. You go to run the setup program and during the prerequisite checks, setup stops. The error listed is:

A restart from a previous installation is pending. Please restart the system and rerun setup.

During the prerequisite checks, Exchange Setup looks in the registry at the following keys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Nine times out of ten, a restart does NOT remediate this error. In order for setup to continue properly, you must do the following:

  • Open regedit: Start > Run > regedit.exe
  • Set the HKLM\SOFTWARE\Microsoft\Updates\UpdateExeVolatile key value to 0 or delete it if present. <– This one is usually NOT present.
  • Delete the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations key.
  • Re-run Setup.

You should now be able to run setup and upgrade your Exchange Server.

PLEASE COMMENT!
HAPPY TROUBLESHOOTING!

References:
A Restart From Another Installation Is Pending
Exchange Setup Fails – A Restart From Another Installation Is Pending
Microsoft Document – A Restart From Another Installation Is Pending