6 Mistakes To Avoid With Exchange 2013 CU Command Line Installations

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:

/IAcceptExchangeServerLicenseTerms

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
Copying Files...
File copy complete. Setup will now collect additional information needed for installation.
Languages
Client Access role: Front End Transport service
Management tools
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.
[PS] D:\>

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
  • PendingFileRenameOperations
• Use Sysinternals Pendmoves.exe to see if there are pending operations
• HKLMSoftwareMicrosoftWindowsCurrentVersionComponent Based Servicing
  • RebootPending

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:

Get-Help about_Command_precedence

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:

    .FindDocs.ps1

If you do not specify a path, Windows PowerShell uses the following  precedence order when it runs commands:

     1. Alias
2. Function
3. Cmdlet
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:

1. Adhere to PowerShell’s stricter path syntax and specify .Setup.exe
2. 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.

Summary

I’d love to hear feedback from the field if this is helpful or if you have other questions / comments on the topic!

To recap:

1. Exchange 2013 does not have setup.com
2. Always specify the license acceptance switch.
3. Close all Exchange tools prior to starting installation
4. Install using elevated prompt
5. Check that there are no pending restart operations
6. Check PowerShell syntax so you don’t re-install the current CU

Cheers,

Rhoderick