Tuesday, November 17, 2015

Resolving Some of Exchange 2013 Uninstall Problems

Hi folks,

In this post I would love to share with you on the issues that I had when uninstalling on Exchange 2013 server. The server version was Exchange 2013 CU9 and it was multi-role server. As you may know Exchange 2013 mailbox server is a combination of all Exchange 2010 server roles.

To uninstall Exchange 2013 binary files I have navigated to the installation files and executed the following command:

setup.exe /m:Uninstall /IAcceptExchangeServerLicenseTerms

So when I launched uninstall all prereqs proved to be successful and installation started. Mailbox services were uninstalled straight away. When the UM services uninstall turn came it prompted me with the following window:

Exchange 2013 uninstall program in order to uninstall UM services component was looking to the following files:
- MSSpeech_SR_en-US_TELE.msi
- MSSpeech_TTS_en-US_Helen.msi

These MSI files belong to UCMA 4.0 which is a prereq for Exchange 2013 installation. When UCMA is being installed it creates the following folder in the Temp folder within end user's profile under which the Exchange 2013 installation is happening. For example: C:\Users\ExchAdmin\AppData\Local\Temp\2\UcmaRuntimeSetup.  After UCMA installation UcmaRuntimeSetup folder is being removed by installation program. To resolve this I had to install UCMA 4.0 on the other computer. I didn't rush to click Next button before file installation to take place. I have copied the whole UcmaRuntimeSetup folder under my account's user profile Temp folder and re-ran the uninstall again.

As you can see UM uninstall completed successfully. 




However I faced another issue when CAS component was being uninstalled I faced the following error displayed both in screen and logged to the Exchange setup log.


This is where this article came to help. The problem was with IIS not being able to load exppw.dll module. You can read more details about it in the article itself. As long as I was concerned I had to edit configuration file for IIS located at C:\Windows\System32\inetsrv\config\applicationHost.config  and add the following into the <globalModules> section:

<add name="exppw" image="C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth\exppw.dll" />

I have executed IISRESET and installation continued for CAS component was successfully uninstall.

First I encountered the following error when uninstalling Front-End Transport component



This is because Microsoft Exchange Active Directory Topology wouldn't stop because of FIP-FS 
Microsoft Filtering Management Service not being properly removed from the server. It's state was running while startup type was set to Disable. After stopping Microsoft Filtering Management Service I was able to do the same with Microsoft Exchange Active Directory Topology.

Uninstall process moved forward and stumbled over the missing cafe_exppw module in IIS.

I had to go back to C:\Windows\System32\inetsrv\config\applicationHost.config and added the following into the </globalModules>  section:

<add name="cafe_exppw" image="D:\Program Files\Microsoft\Exchange Server\FrontEnd\HttpProxy\bin\exppw.dll" />

After this I ran IISRESET and restarted uninstall program. Front-End CAS component has been successfully uninstalled.

Finally uninstall of the language packs went successfully and server has been sucessfully removed from the AD so there was no need to scrapping it out manually

Enjoy!



Restoring Exchange 2013 After Restoring Broken Trust

Hi folks,

I have another adventure to be shared with you. I had an experience when my Exchange server has lost trust with the AD domain. It has been improperly rejoined back to AD by removing AD account to the computer and re-adding it back to the AD by creating a new AD object which resulted in the brand new SID and default group membership.

As you probably know Exchange 2013 (as other versions since 2000) keeps all its configuration settings in the Configuration partition in the AD. After such rejoin a server couldn't retrieve information from the AD and as the result it wasn't able to start any of services.

The resolution of this problem was simple add server back to the following Exchange-related security groups and restarting it (to update access ticket with groups' SIDs):


After server restart I noticed that all the services have restarted successfully and Test-ServiceHealth along the Event Viewer showed no error.

I hope you'll find it helpful.

Enjoy!

Monday, November 2, 2015

Cleaning Up Ghost Move Requests

Hi folks,

I recently had another adventure which I would love to share with you.

I was working on getting rid of the default mailbox databases I ended up with some ghost move requests. When executing Get-MoveRequest cmdlet I saw the following warning:





Removing these move requests was not successful. When attempting to remove move requests I was presented with the error as below:










My investigation of this issue lead me to this thread on TechNet forum. It turned to be very close to what I was having, except for the value of msExchMailboxMoveStatus attribute which was different, however my scenario was different from the one that was discussed there. I was getting value of 1 which probably corresponds to the status value of Queued.

I have created query like below in Active Directory users and computers to retrieve these user objects in ADUC (alternatively ADSIEdit can be used to edit AD attributes on the low level):


When checking move request related attributes in AD I have discovered the following:

msExchMailboxMoveFlags 10
msExchMailboxMoveStatus 1

I have edited each of them and cleared the value as follows:




After clearing each object I would run Get-MoveRequest cmdlet which would clearly show me that the number of ghost mailbox move objects reduces till it finally disappeared when I cleaned all of the user objects.



So now, we are left with the orphaned user accounts. We simply delete them using Active Directory Users and Computers.

I hope this helps you as it helped me.


Enjoy!

First Glance on Exchange 2016 (Part 4). Storage and DAG

Hi folks,

I continue my series on my first experience with Exchange 2016. I have finally found time to write this article. Now as I have configured transport and client access protocol in my lab, the time came to configure mailbox databases and DAGs.

Autoreseed is a great feature since Exchange 2013 which allows to automatically replace failed volume and This is a great article from TechNet Blog that gives a good guidance on how to configure AutoReseed. Autoreseed is managed by 3 important attributes that can be configured on DAG:

 - AutoDagVolumesRootFolderPath is the root folder for the volumes and the default value is E:\ExchVols (in my scenario)

- AutoDagDatabasesRootFolderPath is the root path for the databases and default value is E:\ExchDB (in my scenario)

- AutoDagDatabaseCopiesPerVolume is the amount of databases per volume. I used 2 which allows me to host 2 DBs on volume which is yet another great Exchange 2013/16 feature.

As you know we need to have file share witness and file share directory to be created File Share Witness can't be member of DAG and since we have only one Exchange 2016 role now we will need to use a member server for this purpose.

When a member server is used as a file share witness the Exchange Trusted Subsystem group should be added as a member of the local admins group


I have also created directory C:\FSW\DAG001 which I will use as a witness directory.

As file share witness has been prepared, I moved to configuring of the storage on my Exchange servers.

Create  root folders for mount points collection


Within each root folders I have created folders as follows:

For volumes' mount points:
- E:\ExchVols\Vol001
- E:\ExchVols\Vol002

For Databases mount points:
-E:\ExchDB\DB001
-E:\ExchDB\DB002


After folders have been formatted both volumes with REFS and 64K as unit size (this is now supported according to Exchange 2016 PA but still not a best practice for Exchange 2013) and have mounted both DB and spare volumes to  E:\ExchVols\Vol001 and E:\ExchVols\Vol002:






After this I mounted volume which will store my mailbox databases to E:\ExchDB\DB001 and  E:\ExchDB\DB002 while I left the second volume alone:


Volume that hosts DBs has 3 mount points (one for volume mount point and another 2 for mailbox databases mount points)

Volume that corresponds to spare volume has only one:

After configuring mount points I have created folders for mailbox databases and transaction logs as follows:

-E:\ExchDB\DB001\DB001.db
-E:\ExchDB\DB001\DB001.log
-E:\ExchDB\DB002\DB002.db
-E:\ExchDB\DB001\DB002.log

These 4 folders correspond to the mailbox DBs and transaction logs that will be hosted on my 2016 box. Please note that file structure under E:\ExchDB\DB001, E:\ExchDB\DB002 and E:\ExchVols\Vol001 will be the same as both folders are used to map the same physical volume.

Each mailbox databases will be having its own point point, yet being located on the same physical drive.







As soon as the storage was ready I moved to creating and configuring DAG. I created DAG without CNO and IP address, which is yet another new Exchange 2013 SP1 and 2016 feature which is now recommended by MS. About benefits about having DAG without IP address and CNO you can read here.

Below is the command for creating DAG w/o IP address and CNO:

New-DatabaseAvailabilityGroup -Name DAG001 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer EX2016-FSW01 -WitnessDirectory C:\FSW\DAG001



After DAG was ready I ran the following commands to configure parameters for AutoReseed:

Set-DatabaseAvailabilityGroup DAG001 -AutoDagVolumesRootFolderPath E:\ExchVols

Set-DatabaseAvailabilityGroup DAG001 -AutoDagDatabasesRootFolderPath E:\ExchDB

Set-DatabaseAvailabilityGroup DAG001 -AutoDagDatabaseCopiesPerVolume 2


Configure Datacenter Activation Coordination mode (aka DAC anout which you can read here) for DAG :

Set-DatabaseAvailabilityGroup DAG001 -DatacenterActivationMode DagOnly


As DAG had been created I have added both of my servers into DAG by running the following command for each  of them:

Add-DatabaseAvailabilityGroupServer DAG001 -MailboxServer EX2016-EX01
Add-DatabaseAvailabilityGroupServer DAG001 -MailboxServer EX2016-EX02


After Exchange has installed all the necessary features (Failover Clustering) and added both servers to DAG we check its status by:

Get-DatabaseAvailabilityGroup DAG001 -Status

We need to ensure that both servers are listed under Member Servers and Operational Servers:

After DAG has been successfully created and configured we can create mailbox databases and add copies.

The following code helped me with easy and quick mailbox database creation:

$Server = $(Get-WmiObject Win32_Computersystem).name

New-MailboxDatabase -Name DB001 -Server $Server -EdbFilePath E:\ExchDB\DB001\DB001.db\DB001.edb -LogfolderPath E:\ExchDB\DB001\DB001.log

New-MailboxDatabase -Name DB002 -Server $Server -EdbFilePath E:\ExchDB\DB002\DB002.db\DB002.edb -LogfolderPath E:\ExchDB\DB002\DB002.log

Restart-Service MsExchangeIs

Get-MailboxDatabase Db00* |mount-Database


After we have got our mailbox databases created we can create their copies on other mailbox servers:

Add-MailboxDatabaseCopy DB001 -MailboxServer EX2016-EX001
Add-MailboxDatabaseCopy DB002 -MailboxServer EX2016-EX001


After seeding is completed we need to make sure that all mailbox databases are in good shape and have healthy and working copies though all the environment. It can be achieved by this command:

Get-MailboxDatabase |Get-MailboxDatabaseCopyStatus

Finally we need to get rid of the default mailbox databases. First we need to move arbitration and monitoring mailboxes to the highly available mailbox databases (otherwise we will be presented with the error when we attempt to delete default mailbox database. The following code helps to move them: 

Get-Mailbox -Arbitration |foreach {new-moverequest -Identity $_.Name -TargetDatabase DB001}
Get-Mailbox -Monitoring |foreach {new-moverequest -Identity $_.Name -TargetDatabase DB002}

We can monitor process of the above mailboxes move by executing the following cmdlet:

Get-MoveRequest

As soon as it's completed for all mailboxes we can remove move requests and then remove all mailbox databases by using the Remove-MailboxDatabase cmdlet.

To be continued...