http://technet.microsoft.com/en-us/library/gg675105.aspx
http://technet.microsoft.com/en-us/library/gg650474.aspx
http://social.technet.microsoft.com/wiki/contents/articles/using-services-templates-in-system-c...
I won't focus this blog on how to create a service template but more on how you can track the changes that happen behind the scenes to troubleshoot any issues.
Let's first create a scenario. For simplicity sake, we will use a single VM as this will help us understand the process and use it to track any other deployment. The service template will create a VM with Windows Server 2008 R2 SP1, install the Server App-V agent and then import a Server App-V package to the server.
Once you go through the deployment process and the job starts in the background, this is what occurs:
1) The VHD is transferred from the library to the host via BITS. This process is similar to creating a VM from a template.
2) Once the VM is created on the host, the process will add a virtual floppy to apply all the customization provided in the OS configuration of the template. This will include the addition of roles and features. You can view steps 1 and 2 by connecting to the VM using Hyper-V.
Once SysPrep is complete, the VM is domain joined and running the process that will install a guest VMM agent. You can confirm that this process occurred by connecting to the VM and navigating to %programdata%\vmmlogs. The guest agent will serve as the listener to the SCVMM service to perform actions on the guest VM.
3) Once the agent is installed it will proceed to run scripts in the VM, but before it runs these scripts it needs to transfer them to the guest VM. This step allows you to restart the job if an error occurs. This is done by transferring the custom resource folder from the library to the VM and these files are stored under c:\windows\temp under a folder called scvmmxxx\xxx.cr folder.
4) Once the script files are copied, the Server App-V agent install script will launch the script using c:\windows\temp\ as its working directory. Here it will create two files named GCE_stderrorXXX and GCE_stdoutXXX. These are text files that capture the output of the running script. The GCE_stdoutxxx contains the information of the current actions being performed by the process and the GCE_stderrorxxx file will have any error encountered by the script. If the script encounters an error and stops the process, it will leave this last log in the directory for review. If the process completes successfully it deletes all the contents inside windows\temp
5) Assuming that the process succeeds, we then proceed to transfer the application files specified in the application section of the template. In this case, this is a Server App-V package so it will transfer the package files from the library and store them in the local drive. These files will be stored in c:\windows\MSSCVMMApplications.
Inside this folder you will have two additional folders. One is for Server App-V and it’s here that we store our App-V files. The other is a Webdeploy folder that will store any web apps you have specified in the template.
Since we are using Server App-V, it will launch all PowerShell command to import the application into the Server App-V cache.
NOTE If we were installing a SQL dacpack, the files will be deployed to c:\windows\ MSSCVMMSQLInstance
If the process was successful, you will see the Server App-V application running a service or an icon on the Server App-V agent application list.
The service template process will store logs in c:\programdata\Microsoft\Virtual Machine Manager to track the process of an application installation.
Sample entry of a VMMapplicationmanager.log:
If you are configuring a SQL instance in the service template as part of your deployment, you can gather SQL logs by going to c:\program files\Microsoft SQL Server\100\Setup Bootstrap\log and look in Summary.txt for errors or failures.
Alvin Morales | Senior Support Escalation Engineer
Get the latest System Center news on Facebook and Twitter :
App-V Team blog:
http://blogs.technet.com/appv/
ConfigMgr Support Team blog:
http://blogs.technet.com/configurationmgr/
DPM Team blog:
http://blogs.technet.com/dpm/
MED-V Team blog:
http://blogs.technet.com/medv/
Orchestrator Support Team blog:
http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog:
http://blogs.technet.com/momteam/
SCVMM Team blog:
http://blogs.technet.com/scvmm
Server App-V Team blog:
http://blogs.technet.com/b/serverappv
Service Manager Team blog:
http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog:
http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog:
http://blogs.technet.com/sus/
The Forefront Server Protection blog:
http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog :
http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog :
http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog:
http://blogs.technet.com/b/isablog/
The Forefront UAG blog:
http://blogs.technet.com/b/edgeaccessblog/