I have created a group for our Win7 deployments in safeboot with the $autoboot$ id added to the group. We have written a script with safeboot tool that moves the machine to the group and resets it to group config.
We have the loggin in place that shows us the details of what is exactly executing. We find every now and then an odd machine that does not have the $autoboot$ id synched as it on the first reboot of the winxp to win7 deplyment it prompts for user authentication. The logs are the same for the machines that work fine and the ones that do not, there are no errors found. See the screen below this machine did not work with autoboot and user authentication was required throughout the whole process when upgrading form XP to Win7. Can you please explain why there would be no errors whatsoever but yet only a small number of machines is having this issues? Could this be at a client level?
Unfortunatelly the log is overwritten in the process of upgrading from XP to Win7. I did read about another positing here "$autoboot$ VooDoo. Strange behavior" and it talks about too many machines are synching with with same id. McAfee replied there should be 1-1 relationship with autobot id and the machine. It is very odd that when we deply 60 machines a night maybe 1 would have this issue and when we deploy about 15-20 we have about 8. I will try incorporate the safeboot client log to be copied to a server after the script executes.
Like i said there is a log but the log only shows the new safeboot client info since we install win7 then safeboot client. We are using tools to bypass the safeboot decryption/encryption with zero touch SCCM MDT 2010. We are not able to get to XP safeboot client log as we do wipe the drive in the process but only preserving the safeboot.fs and safeboot.rsv files. I will incoorporate the script to copy the xp log before we wipe the drive so it is preserverd. If i catch any of the machines in future behaving like this i will send you the log. Thanks for the response.
i do not have the problem now as the old machine gets moved back to its original group gets renamed and the user re-attached to it. Autoboot is no longer there as it was attached to the group itself where the machine was moved to. I have an issue at the begining where the autoboot does not work.
perhaps the machine is not syncing the autoboot user then?
You might be better off using the api command "disablesecurity"as it does not require a network connection.
But why would some synch and others not, it is the same process for all. Could you explain more about the "disablesecurity" option and what it does and how it works.
the command is documented in the API manual - that's the best place to start. It's the same as adding an $autoboot$ user, without needing EEM.
as to why it didnt sync - maybe there was a network problem, maybe you rebooted the machine before it finished? Lots of possible reasons. The client log will give you some hints.