The following document is informational and posted as a help to our customers when trouble shooting issues with taking an Image of a machine.
The document applies to: Kaseya 6.2 VSA with Imaging and Deployment 1.0 (KID)
This document writer assumes that you have used this module previously and want further understanding of this process, The process of taking an image with KID involves a number of steps and can fault at anywhere in the process.
When you select a target machine in Imaging and Deployment to be imaged, a few things happen in the background that allow this process to happen both on the target machine and also the repository.
During target selection only machines that are on the same subnet as the repository are shown to you for selection. This process is based on IP address and default gateway.
Now there are only 2 common issues that occur with this selection process:
Machine is not showing for selection
Machine has not been audited or Machine has different default gateway then repository. Check default gateway on target machine or rerun the baseline audit and wait for the results to be upload back into Kaseya then try again.
Machine is selected and still can not get imaged
Technically a machine can have the same IP range, subnet mask and default gateway and be located on the other side of the world. The only difference of course is the connection gateway inside Kaseya that distinguishes between one agent and another.
So for example We have PC1 and PC2
PC1 is on 192.168.2.2/24 and a default gateway of 192.168.2.1 and the connection gateway is 188.8.131.52.
PC2 is on 192.168.2.2/24 and a default gateway of 192.168.2.1 and the connection gateway is 184.108.40.206.
So when you go to select the target you may get a machine that does not actually belong on the same network. You can check the connection gateway from "Agent" -> "Agent Status" and then select the connection gateway from "Select Columns...."
We have had a couple of customers who have selected a machine that was not on the same network as the repository which caused issues. To resolve just verify the computer name for your imaging before making a selection and or check the connection gateway and make sure its the same network.
Machine and Repository are prepared for Image Taking:
Once you have clicked on create image. Several scripts are deployed to the Repository, repository host and the target machine.
These scripts do the following:
* Prepares the Repository host and ensures that the repository VM is started.
* Ensure the repository VM's critical services are operational and ready.
* Tell the repository VM for the MAC address to listen for. Currently wireless is NOT able to PXE boot.
* Then the last script will pump down the required sysprep files to the machine and then fire off sysprep which will then restart the target.
One issue discovered in Windows XP is that sysprep can stall for up to 15 minutes to finish and restart the target machine. We are still trying to find a fix for this issue currently this seems to affect XP machines with SP3. Once we find the root cause of this issue we will post it.
Once the machine has PXE booted and an image is taken, the target machine will restart and go back into Windows (after mini-setup) and then report back to Kaseya that the imaging process was successful.