Disaster recovery?
Have you tried my Backup Script at the Technet Gallery, but now you're wondering what to do with the backup? How do you restore ? What goes where and why?
This is the second of four blog posts trying to explain a couple of concepts regarding backup.
Before reading this post, It is recommend to become familiar with the Basics, CsConfiguration and Topology described in
Part 1 as these are the pillars of the deployment.
CsLISconfiguration.bak
There might, or there might not be a proper LIS Configuration in the deployment in the topology. If there is none, this file is of no use. But if there is a proper LIS Configuration, it takes time to set it up and configure it right.
A lot of good hours can be saved in the event of data loss, if this script has been run. It is a simple global command:
export-cslisconfiguration -filename $backupfile2
This single file contains the entire LIS Configuration the organization has created.
The entire configuration can be re-imported with the
Import-CsLisConfiguration.
A note of importance: The import job will add anything it finds in the file to the configuration. Has there been done any changes to a subnet or two, it might create duplicates with this import.
RGSConfiguration.zip
Route Group Services Configuration is not included in the CsConfiguration or Topology information, and should be backed up separately on regular intervals. The script will take care of the RGS configuration, no matter which server it is installed on. The export command will store agent groups, workflows, queues, holiday sets, business hours, audio files and service configuration settings.
As there can be more than one pool in a deployment, and RGS might be running on several pools, I have tried to catch them all by running a foreach loop for all pools with the "ApplicationServer" role present.
$ApplicationServers = Get-CsService -ApplicationServer <#Find all app servers#>
ForEach ($AS in $ApplicationServers){ <#For each found pool#>
$filepath44 = $filepath4 + "\" + $($AS.PoolFqdn) <#Separate folders if there are more than one pool#>
$backupfile10 = $filepath44 + "\RGSConfiguration.zip" <#Files go in pool folder, not root.#>
New-Item $filepath44 -type directory -force | out-null
Export-CsRgsConfiguration -source ApplicationServer:$($AS.PoolFqdn) -FileName $backupfile10
}
Restoring the RGS can be done with the command
Import-CsRgsConfiguration, and must be targeted at the originating server. Remember to use the "ReplaceExistingRgsSettings" switch if you want to re-import over a faulty configuration.
UserData.zip
User data is probably not the most vital in case of a system failure, but isn't it nice to take care of it, and try to restore as much functionality as possible? It can save the help-desk a lot of complaints and noise if this is restored along with all the other settings.
Again, there can be many pools, and we need to backup all the user-pools in a large environment. This is done with a foreach loop, just as with the RGS above.
$UserServers = Get-CsService -UserServer
ForEach ($US in $UserServers){
$filepath55 = $filepath5 + "\" + $($US.PoolFqdn)
$backupfile13 = $filepath55 + "\UserData.zip"
New-Item $filepath55 -type directory -force | out-null
Export-CsUserData -PoolFqdn $($US.PoolFqdn) -FileName $backupfile13 }
Running the import is just as easy, and is done with the
Import-CsUserData command. Remember to target the correct user-pool when restoring. There are a couple of switches for the import command, depening on the scenario. Import just one user? Import only conference directory information? Import by Routing Group.
There is a second command we can use if we want to update the user data to a logged on user. It is called
Update-CsUserData (Import if the user is offline, update if the user is online)