We currently have laptops using EndPoint Encryption in a windows XP environment. We use Patchlink to deploy patches, computers may need to reboot several times, here is our problem. After the first reboot your done and patching will not continue until you log in past the EndPointEncryption (SafeBoot) screen.
What we would like to do is deploy a batch or VB script to bypass the boot screen, deploy all of the packages, deploy a script to re-enable the boot screen.
Does anyone have such a script that they would like to share?
While I haven't actually done this, I have some experience with $AutoBoot$.
On the console:
Create a copy of your main machine group - add the $autoboot$ ID to it, and make it a controlled group.
When you're ready to patch devices:
Move the machine to the Autoboot group
On the client:
apply the patches, reboot as needed
Once fully done
On the console:
Move the machine back to the original group
Clear the machine settings, by "reset to group configuration" (assuming the original group was NOT a controlled group)
Add any users to the machine
On the console:
Add the $autoboot$ id to the machine(s) to be patched (SBAdmCL - AssignIDs)
force sync (SBAdmCL - ForceSync)
When patching is completed
Remove the $autoboot$ id from the machine(s) (SBAdmCL - RemoveUser)
force sync. (SBAdmCL - ForceSync)
Seems to me that the second option is easier/cleaner. It can be scripted on the server side, however the force sync has to be run from the directory the client is installed into (not sure exactly what that means). Also, you'd have to check the return codes, to see if the sync was successful. I do have some VBScript for reading the return code from SBAdmCL, if you're interested.
You can add two commands to your packages to mitigate your issue without having to move machines to different groups all the time. Use the SBADMCL command: disablesecurity at the beginning of your script to add a local autoboot user. At the end of your script, use the SBADMCL command: enablesecurity to remove the local autoboot user.
Caveat1: You have to go into the machine properties for all of your machines and enable "Allow AutoBoot to be managed locally".
Caveat2: I beleive you also need to copy to all of your machines the SBADMCL.exe, SBADMCL.dll and SBADMCOM.dll files for the command to work locally.
This allows the user to just be created and used locally.Message was edited by: R3k1awyk5 on 12/9/09 8:21:07 AM GMT-06:00
Just to clarify, you only need the DLLs if you are going to use a vb script or a "real" program (written in C or something). If you are just executing a batch file, you only need SBADMCL.EXE. Remember too, that if you do use the DLLs you will need to register them before they will do anything. There is more clarity around this in the scripting guide that comes with the product.
I understand the potential requirements for .exe, dll's etc. which I can push via PatchLink and register them.
Is the "Allow AutoBoot to be managed locally" required if Patchlink is deploying the package as a domain admin.
The way that this deployment works is a group of potentially thousands of machines will have patches deployed to them,
if the machines are off the patching will take place when they come online (that's why doing this through the management console won't work)
Not sure I like allowing autoboot to be managed locally!
I appreciate all the help and responses.
actually, you always need sbadmcl.dll - the .exe and sbadmcom.dll both call it. You don't need to register anything though if you're using the EXE, only if you're using the COM object.
re turning autoboot on and off, you have two choices - the local disablesecurity/reenablesecurity commands, or via the database, setuser/removeuser for $autoboot$.
turning autoboot on is a matter of adding the special user account, turning it off is a matter of removing it.
One comment about using DisableSecurity: When you sync again with the server, the temporary $AutoBoot$ user created by this command is cleared (at least in 5.1.6-5.1.9, and I assume with 5.2.x). For this reason, the last thing you should do before the reboot is to issue a ForceRefresh command and then a DisableSecurity. This way, it's pretty unlikely that another refresh will happen between the time security is disabled and you actually initiate the reboot.