FIM ScriptBox Item
When testing various lab scenarios with FIM, it is a good idea to avoid side effects by just having the data deployed that is relevant for a given scenario. The probably simplest method to have multiple scenarios deployed on a single FIM server is to operate with database backups. To simplify the scenario based database management in a lab environment, I wrote a collection of scripts. The idea of the implementation outlined in this post is to create a folder per scenario:
To keep the logic of the script files simple, each scenario folder has a copy of all script files:
While I like PowerShell, I do also like convenience. Part of this is the ability to start a PowerShell script by double-clicking it. One way of accomplishing this is to use a VBScript to run a PowerShell script. The related VBScript has only 5 lines of script code:
Option
Explicit
Dim
oShell, appCmd
Set
oShell = CreateObject(
"WScript.Shell"
)
appCmd =
"powershell -noexit &'"
& Replace(WScript.ScriptFullName,
".vbs"
,
".ps1"
) &
"'"
oShell.Run appCmd, 4, false
To avoid the need for modifying the script code for each PowerShell script you want to run this way, you just need to save the VBScript in the folder where your PowerShell script is stored. In addition to this, the VBScript must have the same name as the related PowerShell script. The gist of the VBScript code is very simple:
In my testing, I found it helpful to stop the FIM Service and the FIM Synchronization Service and also to restart the SQL Service prior to taking the database backups. That way, you can make sure that there are no open database handles. After taking care of these services, the script codes takes the database backups and stores the related files in the current folder. There is no need to specify parameters for this operation.
The database restore works pretty much the same way as the database backup. First, the FIM Service and the FIM Synchronization Service are stopped and the SQL Server service is restarted. Then, the script code uses the backup files in the current folder to restore to a database state.
As indicated in the introduction, the scripts in this post are not meant to replace a professional backup solution for a production environment. The idea is to provide a quick and convenient way to manage various scenarios on a lab machine.