Restoring mailbox from Exchange 2010 Recovery Database

I recently had a user who hard deleted a folder from their Outlook and was unable to recover the folder using the Recover Deleted Items option in Outlook which meant I was required to recover from backup.  As I haven’t had to do a restore for some time, I found that I had to do a bit of digging into my old notes to find all the cmdlets so after completing the restore I thought it would be a good idea to blog the process so I have something to reference to in the future.

Begin by creating a new recovery database in your Exchange organization with the New-MailboxDatabase cmdlet.  The TechNet article for this cmdlet in Exchange 2010 can be found here:

http://technet.microsoft.com/en-us/library/ee332321(v=exchg.141).aspx

… and for Exchange 2013 can be found here:

http://technet.microsoft.com/en-us/library/ee332321(v=exchg.150).aspx

From what I can tell, the cmdlet hasn’t changed for 2013 so the cmdlet would look something like the following:

New-MailboxDatabase -Recovery -Name Recovery –Server <serverName> -EdbFilePath <databasePath\databaseName.edb> -LogFolderPath <logPath>

… or:

New-MailboxDatabase -Recovery -Name Recovery -Server EXCH01 -EdbFilePath "M:\Mailbox\D
atabase\Recovery.EDB" -LogFolderPath "M:\Mailbox\Logs\Recovery"

Once the cmdlet executes successfully, executing the cmdlet Get-MailboxDatabase cmdlet should display something similar to the following:

Notice how the Recovery field for the recovery database is set to True in the screenshot above.  You should also notice a new dismounted mailbox database created from within the Exchange Management Console:

With the recovery database created, proceed with the restore from your backup application (BackupExec, CommVault, etc) and once the restore is complete, ensure that the mailbox database is mounted:

With the new recovery mailbox store mounted, ensure that the mounted store contains mailboxes by executing the cmdlet:

Get-MailboxStatistics -database RDB

… where RDB is the name of the recovery mailbox database.  If the recovery mailbox contains mailboxes, you should see output that is similar to the following:

The output above from the recovery database should look pretty much the same as the production database so if you were to execute Get-MailboxStatistics -database ProductionDB, you should see a similar output.

Now that we’ve confirmed that the restored mailbox database contains mailbox, the next step is to extract the mailbox contents and either place it into a new temporary mailbox or back into the actual user’s mailbox.  I personally prefer to extract the contents to a temporary mailbox so what I do is create a mailboxrecovery account as such:

Then user the following cmdlet to restore the user’s mailbox into the temporary account:

Restore-Mailbox -Identity myTemporaryAccount -RecoveryDatabase RDB -RecoveryMailbox "Some UserName" -TargetFolder Recovery

… or the following that has actual parameters:

Restore-Mailbox -Identity mailboxrecovery -RecoveryDatabase RDB -RecoveryMailbox "Kathleen Smith" -TargetFolder Recovery

Note that there are times when the recovery database may contain corrupted items so if the restore fails with a exceeded corrupted item count, add the following switch:

Restore-Mailbox -Identity mailboxrecovery -RecoveryDatabase RDB -RecoveryMailbox "Kathleen Rear
don" -TargetFolder Recovery -BadItemLimit 10

Once the cmdlet above executes, you should be able to log into the mailboxrecovery account and see a Recovery folder listed in in the root of the mailbox:

What I usually do is use Outlook to open both mailboxes, then export the folder the user deleted into a PST and reimport it back into the user’s mailbox.  If the folder to be recovered does not have sub folders then you can simply click and drag but if it has sub folders then you won’t be able to because Outlook would prompt you with the message:

Cannot move the items. Cannot copy this folder because it may contain private items.

Identifying which VMware View replica belongs to which virtual desktop

One of the common issues I’ve come across over the past few months for clients was when I was asked to identify which replicas belonged to which virtual desktops in VMware View environments because a lot of my clients suspected that they had orphaned replicas that were not in use.  When approached with such a request, I usually perform one of the following 3 options:

Option #1 – Use the SviConfig.exe command to find unused replicas

VMware actually provides an official KB that demonstrates how to use the SviConfig.exe command to generate a unused-replica-*.txt file that lists replicas that it is able to identify as being unused.  While I’ve found that this doesn’t always work because I’ve had several occasions where the txt file generated was empty, this is the safest route to take. 

Finding and removing unused replica virtual machines in VMware View (2009844)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009844

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

Option #2 – Identifying replica mappings through the ESXi console

Another VMware KB that is available demonstrates how to generate a txt file that contains all of the replica to virtual desktop mappings which can then be used to identify which replicas are actually in use.  I find that this process can potentially be prone to human errors so steps such as renaming the identified replica folders and leaving them for a week rather than deleting them outright should be taken.  The KB that outlines the steps is the following:

Determining which replica disk is used for a linked clone virtual machine (1031842)
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1031842

As I found that the process can potentially be confusing, I’ve documented one of steps I recently went through so that I can reference it in the future:

Begin by executing the following command to find the replicas in the VMX files:

find /vmfs/volumes/ \( -size -1500c \) -name *.vmdk -exec grep replica {} -H \; | grep 'parentFileNameHint=' > replicalist.txt

Use the following command to format the replica information dumped into replicalist.txt and output it to replicalist2.txt:

sed s/:/'-->>'/ < replicalist.txt >replicalist2.txt

From here, the KB article suggests to use the less replicalist2.txt command to view the information but I found that it’s not easy to copy the information from the putty session so simply use the cp command to copy the replicalist2.txt file into a regular VMFS store then use the VMware vSphere Client to download it:

cp /replicalist2.txt /vmfs/volumes/LUN01-ISO/

Proceed with downloading the replicalist2.txt file onto your desktop or laptop and opening the file which should look similar to the following:

Note that all each virtual desktop is represented by the block of text similar to the following:

/vmfs/volumes/4f6480d0-73e03584-c40c-0025b500000c/VIEW4-011_1/VIEW4-011.vmdk-->>parentFileNameHint="/vmfs/volumes/4f6480d0-73e03584-c40c-0025b500000c/replica-496f01b1-630d-4b04-8872-/replica-496f01b1-630d-4b04-8872-.vmdk"

With the replica information in the text file begin traversing through the list of replicas listed in your vCenter:

… and copy each replica:

replica-006164ad-adfe-4fbb-92e6-e32edc60e24f

What’s important to note is that you will need to remove the last string of characters highlighted in red as shown above so that you only have the following:

replica-006164ad-adfe-4fbb-92e6

With the truncated text shown above, perform a search in the text file:

Pay attention to the results that the find feature returns as you are expected to get a return from all of the results because the replicalist2.txt file contains references to the replicas themselves stored on the VMFS stores.  The key here is to determine whether the replica ID shows up on a line that is linked to a virtual desktop and in the example below, it doesn’t:

With this in mind, what this means is that we should be able to unprotect the replica:

Removing orphaned replicas in VMware View 4.6 with sviconfig.exe
http://terenceluk.blogspot.com/2013/03/removing-orphaned-replicas-in-vmware.html

… rename the folder containing the replica on the VMFS store, and then wait a few days before deleting it.  Make sure you’re just renaming the replica in the VMFS folder and not the actual replica in vCenter in case you need to quickly roll back.  Once you’ve confirmed that the replica is indeed not in use because all the virtual desktops continue to be in good health, proceed by renaming the folder that was renamed and then right clicking on the replica in vCenter then delete.

As the example above showed a replica that is orphaned, the following is a demonstration of one that is being used:

replica-07c8e7df-449e-4372-8701-b4e7519223e0

replica-07c8e7df-449e-4372-8701

Notice how the following find research brings us to a line that is associated with a virtual desktop named VIEW46-001:

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

Option #3 – Recompose all desktops with a new snapshot

Another option I’ve found to be the easiest way to clean up old replicas is to perform a recompose of all of the virtual desktop pools with a new snapshot then remove any replicas that are not dated the day of the rollout.  The reason why we can do this is because if all of the desktops are using the new snapshot that was created, the old replicas should get automatically deleted by View and if they are indeed orphaned then you should at least be able to safe rename the folder in the datastore, wait a few days then delete them. 

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

Another possible alternative that I thought would have been a good was a post someone mentioned in the VMware forums:

In a small environment you may be able to locate the linked clones by browsing the database tables

From the Composer database:

    1.    In dbo.SVI_SIM_CLONE, get the REPLICA_ID from the row that the linked clone virtual machine is shown under VM_NAME.

    2.    In dbo.SVI_REPLICA, match the REPLICA_ID found in step 1 under the ID column and get the value for that row under REPLICA_MOID.

http://communities.vmware.com/thread/340859?start=0&tstart=0

Unfortunately, the columns referenced in the tables did not appear to show the mappings so while it would have been nice to be able to use SQL queries to identify the orphaned replicas, it does not appear to be possible to do this.

Lync Server Access Edge service fails to start with: “… service-specific error code -2146762487”

Problem

Lync Server 2013 Role: Lync Edge

Base Operating System: Windows Server 2012

You attempt to start your Lync Server 2013’s Edge server’s Lync Server Access Edge service but notice that the service fails with the following message:

Windows could not start the Lync Server Access Edge on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to the service-specific error code -2146762487.

Reviewing the System logs on the Edge server show event ID 7024 errors logged:

The Lync Server Access Edge service terminated with the following service-specific error: A Certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

You confirm that the root certificate issuing your Edge server’s certificate is listed in the Trusted Root Certification Authorities:

You review the certificate assigned to the external interface for the Edge server in the MMC and notice that the certificates in the chain are all listed as This certificate is OK.:

Solution

For those who have came across one of my previous posts:

Lync Server 2013 Edge server replication issues on Windows Server 2012
http://terenceluk.blogspot.com/2013/04/lync-server-2013-edge-server.html

… will know that I’ve ran into a few challenges with Lync Server 2013 Edge servers on a Windows Server 2012 operating system.  As noted in the post above, Windows Server 2012 is more stringent when it comes to trusted certificates and actions such as mistakenly putting an intermediate certificate in the trusted root certificate store can cause replication to stop working between the Edge and front end server.  What was interesting about this problem indicated in this post is that I had the issuing root certificate on the server’s Trusted Root Certification Authorities and while all indications point to the server trusting the certificate being used by the Edge server, the services did not.  What I ended up having to do to correct this problem was import the intermediate certificate in the chain into my Intermediate Certification Authorities:

https://certs.godaddy.com/anonymous/repository.pki

A bit strange but something I can live with going forward.

Non local administrators are unable to browse and access network shares when logged onto Citrix XenApp 6.5 servers

Environment

Citrix XenApp Server Operating System:  Windows 2008 R2

Citrix XenApp Version: 6.5

Citrix XenApp Hotfix: Rollup 1

Citrix Profile Management Version: 4.1

Problem

You’ve received complaints from various users that when they launch applications published on the Citrix XenApp 6.5 servers, they receive Windows Script Host error prompts similar to the following:

Script:

\\domain.internal\SysVol\domain.internal\Policies\{someGuid}\User\Scripts\Logon\logon.vbs

Line: 16

Char: 1

Error: Permission denied: ‘GetObject’

Code: 800A0046

Source: Microsoft VBScript runtime error

To further troubleshoot, you proceed by configuring the XenApp server to allow users to directly remote desktop to the server.  Upon directly logging onto the server with the user’s credentials, the following is displayed:

While troubleshooting the issue, you also noticed that you are unable to browse the path:

\\domain.internal

Windows cannot access \\domain.internal

You do not have permission to access \\domain.internal. Contact your network administrator to request access.

For more information about permissions, see Windows Help and Support

The server also exhibits the same behavior when you browse directly to a server via the name or IP:

What’s strange is that you are able to ping other servers:

You notice that if you add the user to the local administrators group, the error goes away. 

Solution

While the symptoms described in the following KB:

http://support.citrix.com/article/CTX128255

… did not directly map to the ones described above, I found that the solution was resolved my issue.  The reason why non local administrators were experiencing these symptoms is because of the UsrClass.dat file located in the following directory when the user is logged onto the server:

C:\Users\Default\AppData\Local\Microsoft\Windows

You will also notice the same file stored on the file server that stores the user’s profile management folder:

\\someFileserver\profilemanagement\someUsername\UPM_Profile\AppData\Local\Microsoft\Windows

The solution as described in the article is to delete this file but note the following:

1. You may not be able to delete the UsrClass.dat file from C:\Users\Default\AppData\Local\Microsoft\Windows while the user is logged in
2. Even if you delete the file while the user is logged off, the saved UsrClass.dat will be copied back to the server from the server

To correctly resolve the issue and remove the problematic UsrClass.dat file, first log off as the user to make sure profile management has saved the user’s profile on the file server and no other sessions will overwrite the profile, then go to the user’s profile on the file server and delete UsrClass.dat.  Once this is done, log back onto the server as the user and and ensure the symptoms are gone.

Installing SQL Server 2008 R2 Management Tools fails with the error: “Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1. Please update all Visual Studio 2008 installation to SP1 level, by visiting Microsoft Update.”

Problem

You attempt to install SQL Server 2008 R2 Management Tools on a server or desktop:

but notice that it fails with the error:

Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1. Please update all Visual Studio 2008 installation to SP1 level, by visiting Microsoft Update.

Your SQL Server 2008 R2 setup operation has been cancelled.

Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1.  Please update all Visual Studio 2008 installations to SP1 level, by visiting Microsoft Update.

You attempt to download Microsoft Visual Studio 2008 Service Pack 1 (Installer) from the following URL:

http://www.microsoft.com/en-us/download/details.aspx?id=10986

… but when running the install throws the following error:

Setup has detected that this computer does not meet the requirements to install this update. The following flocking issues must be resolved before you can install Microsoft Visual Studio 2008 SP1 software update.

Installation Requirements:

A compatible version of Visual Studio 2008 was not detected on the system. This update is designed for only the Microsoft Visual Studio 2008 (ENU) product family, and is not compatible with any Express editions.

Solution

This probably was a difficult one to resolve as it took me quite a bit of searching to find a solution and the time it took to find an answer is why I choose to write this post in hopes that I could help someone who may experience the same problem.  What ended up working for me was instructions a user posted in the following thread:

http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/baf09c3f-be97-4bc8-b6d7-bdeea2e3719e

I went ahead and located the SP and SPIndex REG_DWORD attributes in the following registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0
• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0\VSR\1033

… and changed the values from 0 to 1:

Changed to 1:

The user also suggested to change SPName REG_SZ to RTM but I did not have to do this as the install successfully completed with the previous changes:

Citrix XenDesktop 5.6 virtual desktops continuously prompts the message: “You must restart your computer to apply these changes”

Problem

You’ve completed a new build of a Windows 7 master image desktop for XenDesktop 5.6 and proceed with creating the new desktop catalog and add the desktops to a desktop group.  Once the desktops have been deployed, you continue by connecting a desktop in the pool but noticed that you receive the following prompt with the following message:

You must restart your computer to apply these changes

Before restarting, save any open files and close all programs.

You’ve confirmed that your master image does not prompt you for a restart but noticed the desktops in the pool always do.

Solution

This issue was new to me because throughout all of the deployments I’ve done with XenDesktop, I’ve never encountered this.  The only difference between this deployment and all of the others is that this one is built on vSphere 5.1 with vCenter build 947673 and ESXi build 1065491 hosts (my previous deployments are either 4.1 or 5.0).  A quick search on Google reveals the following Citrix KB:

Case Study: MCS-Created Windows 7 VDAs Display 'You must restart your computer to apply these changes' Error Message when Starting
http://support.citrix.com/article/CTX132721

While the environment described in this article does not directly match mine (especially because the hypervisor is Microsoft Hyper-V 2008 R2), I went ahead and tried using the instructions to see if it would correct my problem.  The following are the steps I performed:

1. Shutdown master image
2. Add an additional disk by using an existing identity disk from another desktop in a pool
3. Power on master image
4. Restart the master image a few times
5. Shutdown master image
6. Remove identity disk
7. Create a new snapshot for the master image
8. Update catalog with new snapshot

The Good News:

One of the unexpected behaviors I noticed was that I did not receive a prompt asking me to restart after adding the identity disk to the master image but I can confirm that after performing these steps, the desktops in the pool no longer prompted me to restart the desktop as if it had found and installed new hardware. 

The Bad News:

This was great news until I logged into the master image and noticed that the name of the master image was now the name of the desktop that owned the identity disk I used to attach to the desktop.  I didn’t think too much about this being issue as I figure it probably copied the identity information from the desktop in the pool but what I noticed was that as soon as I changed the name of the master image back to the original, removed it from the domain and restarted, the radio button to join the desktop to the domain would be grayed out:

What makes it more strange is that if I change it back to the same name as the desktop that I used the identity disk and reboot, the option will be available again:

The Workaround:

This was definitely an odd behavior and I wasn’t about to go live with such an issue.  After trying various operations with the master image without any luck, I went ahead and reverted back to a snapshot prior to attaching the identity disk.  Seeing how it appears adding the disk to the master image and booting it up caused Windows to assume the identity provided by the identity disk, I proceeded to try adding the disk without booting up with it.  With the master image powered on, I went to the master image’s virtual machine settings and performed a hot add of the identity disk:

I continued by clicking OK to apply the changes, went to the console of the master image to confirm that identity disk shows up and then went ahead to remove the disk from the master image:

Once the disk was removed, I restarted the master image a few times, created a new snapshot then updated the desktop catalog.  Once the update to the base disk was complete, I noticed that the virtual desktops in the pool no longer prompted for a restart as if new hardware was found and installed.