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

setup.exe /PAD  /IAcceptExchangeServerLicenseTerms

setup.exe /PD    /IAcceptExchangeServerLicenseTerms

Exchange 2013 Schema, AD  And Domain Preparation

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:

Exchange 2013 Lab - CU2 Is Currently Installed

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:

Exchange 2013 CU Install Failed Due To PowerShell Having Open Files

[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 occured.  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 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
    • PendingFileRenameOperations
  • Use Sysinternals Pendmoves.exe to see if there are pending operations
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Component 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

Exchange 2013 CU Install Failed Due To PowerShell Path

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”.

Exploring PowerShell Command Precedence

 

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

Checking PowerShell Environment Path Contents

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.

Exchange 2013 CU - Setup.exe From New CU Is Ignored

 

In this instance we launched using .\Setup.exe  from the root of the D:\ Drive

Exchange 2013 CU - Setup.exe From New CU Is Used

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:

 

Exchange 2013 CU Install - Note Correct Command Precedence

 

Exchange 2013 CU Install - CMD Looks At Current Folder First

 

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

* - (sic)

Technorati Tags: ,
>>>
Comments (23)

  1. anonymouscommenter says:

    Good work!

  2. anonymouscommenter says:

    Thanks for sharing very helpful

  3. anonymouscommenter says:

    Excellent advise on running upgrade though CLI for exchange 2013

  4. Thanks folks - do let me know if you have other questions what would be good to discuss.

    Cheers,
    Rhoderick

  5. anonymouscommenter says:

    Not sure what the new shortcut switch is for /PrepareAD, but you will notice that /PAD for some reason now (cu5 atleast) runs PrepareDomain. The cmd output should mention Organization instead of Domain.

  6. anonymouscommenter says:

    Rhoderick,

    Thanks a ton for sharing this important post

  7. Rhoderick,

    Thanks a ton for sharing this important post

  8. @Steve - Yes, I posted to the blogs.technet.com/MSPFE on this - that article was written by my colleague Frank.

    Cheers,
    Rhoderick

  9. Thanks Sachin - Please share the word the folks you meet as a lot of admins now gravitate to the PowerShell window but do not fully specify the command....

    Cheers,
    Rhoderick

  10. Actually it is recommended to not use the abbreviated command line Switches, as only the full command line switches work as expected.

    /pad is the abbreviated switch for /PrepareAllDomains, not /PrepareAD

  11. Hi Thomas!

    Agreed. I posted the initial article on this that Frank wrote. I should add a note here as well, since this was written in the CU2 /CU3 timeframe.

    Cheers,
    Rhoderick

  12. anonymouscommenter says:

    you guys had some GD bad luck....lol.

    <EDIT - removing profanity>

  13. Ezzaldeen says:

    hello every one : i incompletely install exchange 2013 sp1 on my domain but i faced some problem . i removed it from ADSIT.msc
    and format the Exchange 2013 Server and install anew OS windows server 2012 R2 Stander . but when we need to make anew preparation for AD from my DC .\setup /preparad preparation field give me restart is pending and Default Exchange step Directory not found i need your help

    1. Removing currently supported versions of Exchange using ADSIEdit.msc is not supported. Even with Exchange 2003 it was strongly recommended NOT to do this.

      If this is a test lab, might just be easier to remove AD and go again from scratch.
      Cheers,
      Rhoderick

  14. Rad says:

    Thank you very much, this article help a bunch...I was having issues installing CU3 when I kept getting the message about Update 2...
    Your explanation really help me understood what it was looking at and why I kept getting the same thing over and over even though I was running the same command from source on a remote machine and got the correct update number...

    Thank you

    1. Glad it helped Rad, and thanks for taking the time to post!

      One thing to mention, I hope there is a 1 missing in your comment, i.e. installing CU13 as CU3 is no longer supported
      https://blogs.technet.microsoft.com/rmilne/2015/04/14/end-of-exchange-2013-rtm-support/

      Cheers,
      Rhoderick

  15. Lee Myers says:

    hello, i'am getting the following error message when upgrading to exchange CU14 update

    Welcome to Microsoft Exchange Server 2013 Cumulative Update 11 Unattended Setup
    Languages
    Mailbox role: Transport service
    Client Access role: Front End Transport service
    Mailbox role: Client Access service
    Mailbox role: Unified Messaging service
    Mailbox role: Mailbox service
    Management tools
    Client Access role: Client Access Front End service

    Performing Microsoft Exchange Server Prerequisite Check

    FAILED
    An unexpected error has occurred and a Watson dump is being generated: Could no
    t find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServic
    eEndpointsConfig.xml'.

    1. Hi Lee,

      Re-download the ISO just to double-check what is happening. Want to rule out bad media.

      Cheers,
      Rhoderick

  16. Lee Myers says:

    [11/29/2016 12:06:09.0666] [1] [ERROR] Could not find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServiceEndpointsConfig.xml'.
    [11/29/2016 12:06:09.0666] [1] [WARNING] An unexpected error has occurred and a Watson dump is being generated: Could not find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServiceEndpointsConfig.xml'.
    [11/29/2016 12:07:58.0447] [1] [ERROR] Could not find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServiceEndpointsConfig.xml'.
    [11/29/2016 12:07:58.0447] [1] [ERROR] Could not find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServiceEndpointsConfig.xml'.
    [11/29/2016 12:07:58.0480] [0] [ERROR] Exception has been thrown by the target of an invocation.
    [11/29/2016 12:07:58.0521] [0] [ERROR] Could not find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServiceEndpointsConfig.xml'.
    [11/29/2016 12:07:58.0522] [0] [ERROR] Could not find file 'C:\Program Files\Microsoft\Exchange Server\V15\bin\EnterpriseServiceEndpointsConfig.xml'.
    [11/29/2016 12:07:58.0522] [0] CurrentResult SetupLauncherHelper.loadassembly:444: 1
    [11/29/2016 12:07:58.0522] [0] The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the :\ExchangeSetupLogs folder.
    [11/29/2016 12:07:58.0524] [0] CurrentResult main.run:235: 1
    [11/29/2016 12:07:58.0524] [0] CurrentResult setupbase.maincore:396: 1
    [11/29/2016 12:07:58.0526] [0] End of Setup
    [11/29/2016 12:07:58.0526] [0] **********************************************

  17. Todd says:

    oh man, thanks for sharing

  18. Akrofly says:

    Hello and a happy 2017.
    I have inherited a system were someone installed the current CU again on a mailbox server DAG member (the issue you mentioned above)
    The server was inoperative.
    As I inspected the system I found that the the servercomponentstate was locked in "INACTIVE" by the functional requester.
    I got it to work as a DAG member and all is well except for the fact that CU14 (Exchange 2013) constantly fails due to missing files from the unifiedmessaging folder under "C:\Program Files\Microsoft\Exchange Server\V15\"
    Inspecting the exchange 2013 installation folder I see quite a bit of files missing.
    Any ideas how to recover the missing files without scratching the server and reinstating a fresh DAG member?

    1. Akrofly says:

      Are the files missing because of the same cu13 reinstallation since it was run from the existing path?
      Can a second reinstall of the current CU13 fix the missing files only this time running it from the real CU13 and not the OS path?

      1. Akrofly says:

        The problem was solved by simply generating empty folders with the same names as those that were missing and ran the installation of CU14 again, it worked like a charm.

Skip to main content