Exchange Server 2013 : Deploying an Exchange 2013 server (part 2) - Setup logs, Uninstalling Exchange

11/15/2013 8:31:06 PM

3. Setup logs

If any problems occur during the installation, you can usually find the reason in the files the installation procedure places in the \ExchangeSetupLogs folder. The contents of the main installation log, ExchangeSetup.log, are quite interesting to review because you can find details there of all the commands used to install Exchange on a server, including the changes applied to Active Directory. Exchange is tremendously verbose in terms of the information written into the setup log. The log is broken into major activities, which are indicated by a long line of asterisks, and minor activities, which are indicated by a shorter line. Initialization of the installation process is a major activity; running a Windows PowerShell script to perform a single task is a minor activity.

As a glance at Figure 3 reveals, there’s a mass of data within the setup log. Most of the data captured in the logs are not useful unless you encounter a problem during an installation and need to find out why the problem occurred. Even so, most of the information you’ll need is right at the end of the log, where you’ll see details of the problem the setup program experienced and the actions it took to unwind the installation. The remainder of the data in the log is unlikely to be looked at by anyone except a support specialist who’s tracking down an elusive problem.

A screen shot of the Notepad text editor being used to review the contents of the Exchange setup log. In this case, an error has been encountered when Exchange attempted to contact an Active Directory domain controller.

Figure 3. Examining the contents of ExchangeSetup.log

In addition to the setup logs, the ExchangeSetupLogs folder contains a number of Windows PowerShell scripts that the installation procedure generates to perform different steps, including the configuration of the various server roles installed on the server. The fact that Exchange uses Windows PowerShell in this manner underscores the importance of scripting to the product, as do the many examples of scripts built to perform uninstalled installations.

If problems persist and you can’t install Exchange, or if Exchange doesn’t work as expected after the installation, Microsoft support is likely to ask you to provide information such as the installation logs and the server’s application event log to enable the support team to understand what happened and fix any problems. The team might also ask you to run the Exchange Trace Analyzer utility (ExTRA) to gather debugging information. ExTRA runs in the background to gather information about Windows and Exchange at an additional level of detail.

Tip

One small detail that occurs during an installation is that the path for executables is updated with the location of the Exchange binaries. This is a nice feature because it avoids the need for administrators to search file locations when they want to run Exchange utilities such as Eseutil.exe.

4. Uninstalling Exchange

No one would ever remove Exchange from a computer unless it was a test box or it was time to decommission the server after upgrading to a new release. If you need to remove Exchange, however, two methods are available to uninstall a single role, multiple roles, or a complete Exchange server:

Run Setup.com from the command line. For example, to remove Exchange 2013 from a server, run the Setup.com /Mode:Uninstall command.
In Control Panel, click Uninstall A Program and then select Exchange 2013 from the list of programs. This invokes the GUI setup program in uninstall mode.

Note that unlike Exchange 2010, Exchange 2013 does not support the removal of a single role from a server; you must remove Exchange completely and then reinstall the role you want to keep. When the time comes to remove roles or a complete server, the first step is to ensure that data is transferred off the server before you run Setup. Although this is not a comprehensive checklist, these steps are among those you should review before you decommission a server:

Move mailboxes to databases on other servers (or move complete databases if the server is a member of a DAG). Disable automatic database activation on the server to prevent the DAG from activating any copies that remain on the server.
Exclude the mailbox databases on the server from automatic provisioning so that an administrator does not inadvertently create new mailboxes in those servers.
After all mailboxes, including system mailboxes such as discovery search and arbitration mailboxes, have been moved from the databases, dismount and remove the databases.
Remove the server from its DAG if it is a member.
Clear any outstanding move requests for databases hosted by the server.
Disable group metrics generation and make sure that another server in the organization takes on this task.
Remove the server from any send connectors for which it is a source.
If the server being removed is a CAS, ensure that connectivity (external and internal) for all supported client types will continue to function.

After you relocate mailboxes, it’s wise to leave the server in place for a couple of days to check that everything continues to run smoothly. You should check the event logs on the server to be decommissioned and on the servers to which you have transferred work to ensure that no problems are flagged. You could then take the server offline for a period to see whether anything breaks. Finally, after you are sure that everything is ready to proceed and no lurking problems exist, you can run Setup in removal mode.

Inside Out Moving pesky arbitration mailboxes

Sometimes you’ll be ready to remove a database from a server that you want to decommission when Exchange complains that the database contains one or more mailboxes. When you run the Get-Mailbox cmdlet to check, nothing is returned. This probably occurs because one or more arbitration mailboxes are held in the database, and these don’t show up when Get-Mailbox is run unless you add the /Arbitration switch. The solution is to move the mailboxes before proceeding. You can do this by finding all the arbitration mailboxes in the database and piping the results into the New-MoveRequest cmdlet to move them to another database. After the moves are complete, you should be able to remove the database and uninstall the server.

Set-ADServerSettings –ViewEntireForest $True
Get-Mailbox –Database DB1 -Arbitration | New-MoveRequest –TargetDatabase DB2

If a lingering arbitration mailbox isn’t the issue, Exchange might be protesting because a public folder is homed in the database. You can check with:

Get-Mailbox –PublicFolder – Database DB1 | Remove-Mailbox

If these steps don’t work, and Exchange is still complaining about one or more lingering mailboxes, you can use ADSIEdit to examine the HomeMDBBL attribute (Figure 4) of the database to see the list of linked mailboxes that regard the database as their home. (Enable view read-only backlinks by using the Filter button when looking at the database properties to see this information.) If all this seems to be too much work, you can just remove the database by using ADSIEdit.

A screen shot taken when ADSIEdit is used to examine the attributes of a mailbox database. In this case, we’re looking at the HomeMDBBL attribute to see all of the mailboxes that are linked to the database.

Figure 4. Viewing the list of mailboxes back-linked to a database

Entering the dark zone

You enter the Exchange dark zone when a problem exists that cannot be resolved with an option available through EAC, a Windows PowerShell command, or some other common utility. It might be that a software or hardware bug has caused incorrect data to be written into the Exchange configuration data in Active Directory or that an administrator has updated a program and caused a conflict with Exchange. Whatever the case, it is a bad situation when Setup won’t proceed and you’ve tried all suggestions, including those found on the Internet.

At this point, some advocate using the ADSIEdit utility in an attempt to edit or remove Active Directory that is inaccessible through other means. For example, if Setup is unable to remove Exchange from a server, and you really want to remove it from the organization, you could use ADSIEdit to remove the server object from Active Directory and then delete the computer account. This is a radical step, and it’s certainly not something to attempt without a comprehensive understanding of what you’re about to do, but it is a method that has often been used to remove a stubborn server.

The Exchange development group has been asked to help by providing a new setup mode to delete a server when an administrator is absolutely sure that this is what he wants to do. Unhappily, they still haven’t given us a command something like this:

Setup /m:Remove /YesIReallyMeanIt /TakeNoExcuses /BlowitAwayServerName

Others

- Installing Exchange 2013 : Deploying an Exchange 2013 server (part 1) - Running Setup

- Installing Exchange 2013 : Creating the Exchange 2013 organization

- Installing Exchange 2013 : Types of Active Directory deployment that support Exchange

- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 4) - General Application Settings, Apps, Navigation

- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 3) - Backup and Restore, Security

- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 2) - System Settings, Monitoring

- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 1) - Application Management

- Monitoring Microsoft Lync Server 2010 : Installing Operations Manager 2007 R2 (part 2) - Importing Management Packs, Deploying OpsMgr Agents

- Monitoring Microsoft Lync Server 2010 : Installing Operations Manager 2007 R2 (part 1) - Single Server OpsMgr 2007 R2 Install, Prerequisite Checker

- BizTalk Server 2009 : Executing Business Rules (part 2) - Calling the Engine from a .NET Application, Policy Chaining