The syntax to install Exchange Cumulative Updates (CU) via the command line is pretty straight forward. However there are some common themes that still pop up in the TechNet forums, cases and customers that I speak with. So I wanted to discuss some of the issues that can and will arise. There are a range of issues in here from:
Setup can’t continue with the upgrade because the PowerShell has open files *
You need to accept the license terms to install Microsoft Exchange Server 2013
I just installed a CU and it is not showing in Add/Remove programs
I just installed a CU and it is not showing in Programs and Features
Exchange 2013 CU was installed but version number stayed the same
Exchange 2013 CU was installed but build number stayed the same
Update 11-12-2013: Added note back to the TechNet Exchange 2013 unattended documentation
Update 15-10-2014: Added note to not run the shortcut commands. Full syntax should be used to prepare the Schema and AD.
Meet Our Guinea Pig Server
No it is not a cute and fluffy rodent! On this Exchange 2013 RTM CU2 lab machine, the CU3 bits are present on the D: drive which is a DVD. The necessary steps to update the AD schema, etc. were already done by the relevant AD team. Well that was me wearing a different hat – the grumpy triangle hat!
We can see the commands executed below:
Note: This article was written in the CU2 timeframe. There are issues running the shortcut commands in the newer Exchange 2013 builds, Please use the full syntax and not the shortcut syntax that is shown below.
setup.exe /PS /IAcceptExchangeServerLicenseTerms
</em><em>setup.exe /PAD /IAcceptExchangeServerLicenseTerms
<em>setup.exe /PD /IAcceptExchangeServerLicenseTerms
So let’s not worry about the Prepare Schema aspects or the permissions required to execute them. We want to focus on a simple server installation.
We shall look at server called F2013-CAS1, which is an Exchange 2013 CAS with CU2 installed. In the DVD drive Exchange 2013 RTM CU3 is loaded. The starting build version, which is CU2, can be seen below:
What are some of the issues that can cause grief when installing ?
Issue #1 – Running setup.com
There is no setup.com in Exchange 2013. Setup.exe is used for both GUI and command line installations. It’s a habit to get out of. And yes, I frequently autopilot to this!
Issue #2 – Not Specifying License Acceptance Switch
In an automated Exchange 2010 installation there was a pause to allow the admin the chance to reject the license terms. If the admin did nothing then the license was accepted. In Exchange 2013 the license terms must be explicitly accepted. Using GUI setup we have the ticky box, and in command line setup we use this setup parameter:
If this is not entered on a command line task, then the task will fail. You will be the lucky owner of the following error message:
Welcome to Microsoft Exchange Server 2013 Cumulative Update 3 Unattended Setup
You need to accept the license terms to install Microsoft Exchange Server 2013.
To read the license agreement, visit http://go.microsoft.com/fwlink/p/?LinkId=150127. To accept the license agreement, add the /IAcceptExchangeServerLicenseTerms parameter to the command you’re running. For more information, run setup /?
Issue #3 – Exchange Tools Left Open
This could also affect an Exchange 2010 installation as well. The issue here is that there are Exchange tools still running on the server when trying to apply the CU. Make sure all other users are logged off, you are the only one connected and the Exchange Management Shell is closed.
Installation should be done from an elevated prompt. DO NOT use the Exchange Management Shell to launch command line Exchange installations. Your installation will fail as PowerShell will still have files open and you will get the following error:
[PS] D:\>.\Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms
Welcome to Microsoft Exchange Server 2013 Cumulative Update 3 Unattended Setup
File copy complete. Setup will now collect additional information needed for installation.
Client Access role: Front End Transport service
Client Access role: Client Access Front End service
Performing Microsoft Exchange Server Prerequisite Check
Configuring Prerequisites COMPLETED
Prerequisite Analysis FAILED
Setup can’t continue with the upgrade because the powershell (4484) has open files. Close the process, and then restart Setup.
For more information, visit: http://technet.microsoft.com/libraryEXCHG.150)/ms.exch.setupreadiness.ProcessNeedsToBeClosedOnUpgrade.aspx
The Exchange Server setup operation didn’t complete. More details can be found in ExchangeSetup.log located in the < SystemDrive>:\ExchangeSetupLogs folder.
If you are interested, use Process Explorer to verify which process running is responsible for the open files.
Issue # 4 – Not Using An Elevated Prompt
Ensure that the prompt being used is elevated if UAC is enabled. This ensures that the setup process is launched with the required rights. As with some of the other issues above, this was also an issue with Exchange 2010 installations. Recent Exchange 2010 updates error and say the installation ended prematurely, though some of the earlier Exchange 2010 updates would do some unpleasant things.
Always install from an elevated command Prompt!
Issue # 5 – Pending Restart
Make sure that the server is in a known good state to receive the CU. There should be no pending restart tasks on the server which could be caused by installing other pieces of software. In larger organisations ironically this may not be caused by the Exchange admins, rather other teams that are responsible for managing different aspects of the company. This could be due to installing or updating backup, AV, monitoring, patching, hardware tools or VM add-ons. The other team is happy that their maintenance went OK, but they left a pending file operation that needs a restart but the required restart never occurred. The poor Exchange admin either has to get permission to deviate from their prescribed maintenance activity or abort and reschedule for later.
There are several places a restart flag could be squirreled. This is not an exhaustive list:
Look at HKLMSYSTEMCurrentControlSetControlSession Manager
- Use Sysinternals Pendmoves.exe to see if there are pending operations
- HKLMSoftwareMicrosoftWindowsCurrentVersionComponent Based Servicing
Issue # 6 – Reinstalling The Existing CU
We saved the best for last! This is one of those “tearing my hair out as I swore that I just installed that CU” but:
The Exchange version remains the same. Or put another way the build number remains the same.
I do not see my CU listed in add/remove programs (or whatever it is called this month).
I installed a CU but an issue that was meant to be resolved is not fixed
There are a few more variants of the angst described above, but let’s discuss the issue rather than go down that rabbit hole further. As we saw in Issue #3, running setup in the Exchange Management Shell (EMS) causes issues so what some admins then do is close EMS and then fire up a standard PowerShell prompt. As discussed in Issue #4 this should be elevated.
In the example below, we can see that this is indeed a standard PowerShell prompt which is elevated. Note that we changed to the root of D: which is our Exchange 2013 RTM CU3 installation media. All good so far! We then kick off the CU3 installation process.
setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms
That looks great! But is it? The answer is no.
If you look very closely at what Exchange has said to us in the very first line we see this
Welcome to Microsoft Exchange Server 2012 Cumulative Update 2 Unattended Setup
Did you spot the issue there? Go back and re-read if not.
You should be thinking what the heck? I Launched CU3 setup, and Exchange is telling me that it’s re-installing CU2??? I already installed CU2, why is it re-installing the old CU?
This is not an Exchange issue, this is a base PowerShell piece of functionality. PowerShell wants to know exactly where the item you are running is located and in this case because you did not specify a local copy of setup.exe using syntax .Setup.exe then it has gone and searched through the path statement to locate a copy.
Let’s take a simple example to open a text file called File.txt in the C:Temp folder. Look what happens below when entering only “File.txt” and compare that to “.File.txt”.
Note the last command completed successfully, it is prefixed by .
This prefixing happens automatically with tab complete, so you may not have previously noticed this. But when pasting in commands into PowerShell make sure . is used to explicitly state what command you are running . If we check the PowerShell help by reviewing the output from:
To run a script that is in the current directory, specify the full path, or type a dot (.) to represent the current directory. For example, to run the FindDocs.ps1 file in the current directory, type:
If you do not specify a path, Windows PowerShell uses the following precedence order when it runs commands:
4. Native Windows commands
What copy did it find? It found the CU2 Setup.exe that is the Exchange BIN folder. The BIN folder is included in the path which is why we located it. We can see this here.
Get-ChildItem env:path | Fl
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Microsoft\Exchange Server\V15\bin;C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Native
And for giggles, lets use Process Monitor to show which Setup.exe has been used. When . is omitted and only setup.exe is entered in PowerShell. we observed Setup.exe being located in the C:Program Files Folder even though we launched from the D: drive.
In this instance we launched using .Setup.exe from the root of the D: Drive
Bit of a difference, no?
The Exchange 2013 Unattended Mode documentation on TechNet does state that a command prompt should be used.
Note that the PowerShell path may be different from the CMD path statement.
How do we fix this? There are two choices:
Adhere to PowerShell’s stricter path syntax and specify .Setup.exe
Use elevated CMD prompt
Successful examples of both are shown below:
Bonus Issue # 7 – Shortcut Syntax
This is an addition after the initial post. In the newer builds of Exchange 2013, there are some issues with running commands with the shortcut syntax.
Please ensure that you are using the full syntax to prepare the Schema and AD. If you look at the TechNet documentation the full syntax is used.
I’d love to hear feedback from the field if this is helpful or if you have other questions / comments on the topic!
Exchange 2013 does not have setup.com
Always specify the license acceptance switch.
Close all Exchange tools prior to starting installation
Install using elevated prompt
Check that there are no pending restart operations
Check PowerShell syntax so you don’t re-install the current CU