I've had some real difficulties installing CU2. I have two issues, the first I resolved in a very strange way, the second was even worse and I don't why it would have been a problem in the first place.

First off I should mention I am using a licensed Exchange 2013 Enterprise Edition on a licensed Server 2012 Standard Edition. My machine (a VM) meets all the system requirements.

Issue 1 (resolved): Crazy issue where all of a sudden the installer just poofs and vanishes, and then deletes all but just a couple of the installer files along with it. Here's my story:

After installing Exchange 2013, I saw that an empty folder was left at C:\Users\<user who installed Exchange 2013>\ExchangeLanguagePack\

When I ran the CU2 exe, it asked me where I would like to unpack all the folders, and I thought the above directory would be a nice choice (rather than have a splattering of files on the desktop or the main user folder, plus the browse dialog doesn't allow creation of new folders on the spot).

The extraction would work fine. When I would run setup.exe, the installer launched fine initially, asked to check updates (yes), but then it would magically vanish when it was in the middle of "checking space requirements" (paraphrased -- basically making sure I had enough free space on the disk drive).

It was just gone. Then all but a couple of the extracted files from C:\Users\<user who installed Exchange 2013>\ExchangeLanguagePack\ were deleted too.

I tried this three times with the exact same results every time. Finally, after a fourth successsful extraction, I decided to copy the contents of C:\Users\<user who installed Exchange 2013>\ExchangeLanguagePack\ to C:\Users\<user who installed Exchange 2013>\Desktop\CU2\

Then it worked!

Evidently the original folder I tried installing from is a special folder that can't be used during the CU2 install? Seems like a bug to me.

Issue 2 (unresolved): Install was going fine until I got to step 16 (Client Access role: Client Access Front End service), when the install failed. and had the following error text:

Error:
The following error was generated when "$error.Clear(); 
          $vdirName = "PowerShell (Default Web Site)";
          $InternalPowerShellUrl="http://" + $RoleFqdnOrName + "/powershell";
          $vdir = get-PowerShellVirtualDirectory -server $RoleFqdnOrName -DomainController $RoleDomainController | where { $_.Name -eq $vdirName };
          if ($vdir -eq $null)
          {
            $vdirName = "PowerShell";
            new-PowerShellVirtualDirectory $vdirName -InternalUrl $InternalPowerShellUrl -DomainController $RoleDomainController -BasicAuthentication:$false -WindowsAuthentication:$false -RequireSSL:$false -Role ClientAccess;
          }
          else
          {
            update-PowerShellVirtualDirectoryVersion -DomainController $RoleDomainController;
            Set-PowerShellVirtualDirectory $vdirName -InternalUrl $InternalPowerShellUrl -DomainController $RoleDomainController -WindowsAuthentication:$false -RequireSSL:$false;
          }
        " was run: "The Active Directory object for virtual directory 'IIS://RDP3-2013EX28.p3.ld/W3SVC/1/ROOT/PowerShell' on 'RDP3-2013EX28' could not be created. This might be because the object already exists in Active Directory. Remove the object from Active Directory, then re-create it.".

The instructions from the error were quite baffling: why would the object need to be created if it already exists?

Nevertheless, I took a backup of the virtual directory via the command:

get-WebServicesVirtualDirectory | fl > ~\EWS.txt

However, strange thing about that is although Exchange 2010 only has one EWS VD, 2013 seems to have two, one for both the Back End and the Main Web Page. Based on the error text it seemed to be complaining about the back end one, although I couldn't be sure (since the virtual directory path didn't line up perfectly with either). Also, given how long the install of this takes, I didn't want to risk only removing one to only have the install complain about the other -- so I removed both 2013 VDs through the following commands:

remove-WebServicesVirtualDirectory -identity "RDP3-2013EX28\EWS (Exchange Back End)"
remove-WebServicesVirtualDirectory -identity "RDP3-2013EX28\EWS (Default Web Site)"

When I would run each of these commands, I would get the following warning:

WARNING: Outlook Web App won't function correctly if you remove the Exchange Web Services virtual directory
"RDP3-2013EX28\EWS (Exchange Back End)". To disable Exchange Web Services without blocking access to Outlook Web App,
you can use "Set-CASMailbox -Identity <user> -EwsEnabled:$false" or "Set-OrganizationConfig -Identity <org>
-EwsEnabled:$false".

Confirm
Do you want to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"):

So given that warning, I decided to heed its advice and I ran the first command given with my username. When I did that, nothing was printed out, so I assumed it completed successfully? Nevertheless, when I would run the remove commands above again, I would get the same warning. Ok, what the hell, let's just continue. So I removed both Exchange 2013 VDs in this fashion.

Since I had the backup made earlier, I figured if I really needed to, I could just re-add them in with the new-WebServicesVirtualDirectory and set-WebServicesVirtualDirectory commands.

Unfortunately, after I removed both VDs from the AD, the only recourse I had in the installer was to exit -- there was no retry button. So I had no choice but to click exit, and then the installer immediately closed out -- there was no further prompting or cleanup of any kind.

Well, I went to run the installer again, and right away it said it detected an incomplete set-up and would try to finish the install. Now, instead of only 2 steps remaining (before I was on step 16 of 18), there were now 9 steps.... but it finished to completion... I think? I saw it get to step 8 of 9 (which was "finalizing setup"), I stepped away for a moment, then when I came back, the installer had vanished? So I think it just finished and closed... maybe?

When I look at the version number of Exchange in Add or Remove Programs, I see it says Cumulative Update 2 is installed and the version number was bumped up to 15.0.712.22.

So, in conclusion... everything is working OK? Nope, I went and checked on the EWS VDs to see if they had been added back in. I ran get-WebServicesVirtualDirectory, and I that they were NOT added back in...  so now I have a headache of figuring out how to get EWS working properly now...

These are some pretty nasty install bugs Microsoft. I think you need to get these worked out, because I doubt I won't be the only one running into these problems.

Not sure if anyone here is going to be able to provide feedback or not, but at the very least I might provide some insight to others who run into these issues...

Thanks,

Jon

Hi Jon,

I have a test environment where I have run into the same issues and am trying to resolve them - Hopefully!

Have you done this?

-----------------------------------------------------------------------------------------

Upgrading/Deploying Cumulative Update 2

Unlike previous versions, cumulative updates do not use the rollup infrastructure; cumulative updates are actually full builds of the product, meaning that when you want to deploy a new server, you simply use the latest cumulative update build available and do not necessarily need to apply additional Exchange Server updates.

Important: To prevent issues during the installation or upgrade of Exchange 2013 RTM CU2, you should ensure that the Windows PowerShell Script Execution Policy is set to Unrestricted. Failure to do so could cause the Exchange 2013 server to be in an unusable state and some downtime could occur. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the Exchange 2013 Server(s). If the policies are NOT set to Unrestricted you should use the resolution steps in the following article to adjust the settings KB 981474.
Active Directory Preparation

Prior to upgrading or deploying the new build onto a server, you will need to update Active Directory. For those of you with a diverse Active Directory permissions model you will want to perform the following steps:

Exchange 2013 RTM CU2 includes schema changes. Therefore, you will need to execute setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms.
Exchange 2013 RTM CU2 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms.
Note: If your environment contains only Exchange 2007, and you upgrade to Exchange 2013, keep in mind you cannot deploy Exchange 2010 in that environment at a later time. If you foresee a need to deploy Exchange 2010 servers into your environment, deploy an Exchange 2010 multi-role server (with all four servers roles) prior to executing Exchange 2013 setup.exe /PrepareAD. As long as you retain at least one role of each legacy server, you will continue to be able to install additional servers of that version into your coexistence environment. Once you remove the last server role of a legacy version, you will no longer be able to reintroduce that version into the environment.

Server Deployment

Once the preparatory steps are completed, you can then deploy CU2 and start your coexistence journey. If this is your first Exchange 2013 server deployment, you will need to deploy both an Exchange 2013 Client Access Server and an Exchange 2013 Mailbox Server into the organization. As explained in Exchange 2013 Client Access Server Role, CAS 2013 is simply an authentication and proxy/redirection server; all data processing (including the execution of remote PowerShell cmdlets) occurs on the Mailbox server. You can either deploy a multi-role server or each role separately (just remember if you deploy them separately, you cannot manage the Exchange 2013 environment until you install both roles).

If you already deployed Exchange 2013 RTM code and want to upgrade to CU2, you will run setup.exe /m:upgrade /IAcceptExchangeServerLicenseTermsfrom a command line after completing the Active Directory preparatory steps or run through the GUI installer. Deploying future cumulative updates will operate in the same manner.

Thanks for the response Andrej,

Where did you get that information from? I have not seen it before. These are the articles I consulted during the CU2 install:

http://technet.microsoft.com/en-us/library/jj150489%28v=exchg.150%29.aspx
http://technet.microsoft.com/en-us/library/jj983803%28v=exchg.150%29.aspx

Also, following the nested linked articles in the above links, I did not find the information you provided.

Right now, my Exchange 2013 CU2 environment seems to be functioning fine with the exception that 2013 EWS have been removed.

I would prefer to try and fix this issue without reinstalling the server. I tried running the two commands you gave:

setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

However even though both ran successfully, I still don't have the 2013 EWS VDs:

[PS] C:\Windows\system32>get-WebServicesVirtualDirectory
Name                                    Server                                  InternalUrl
----                                    ------                                  -----------
EWS (Default Web Site)                  RDP3-2010EX01                           https://rdp3-2010ex01.p3.ld/EWS/Exch...

Is there any automated way to add these back in (other than by using new-WebServicesVirtualDirectory command)?

Thanks,

Jon