I've literally run thousands among thousands of wsusoffline doupdate.cmd passes and I have never once run into the problem I'm seeing right now. For every release I've always stripped out the code for things that would violate change control conditions, like creating a woutempadmin account, registry changes, power scheme changes, auto logins, etc. I don't use any network path installations either due to some boxes being DMZ'd etc. What I do is make a OS specific package so for 2012R2 i'll only send over the 2012r2 folder which contains all the required folders for scripting and it'll have the cpp/dotnet/w63-x64/win/ folders as well to keep package sizes small. I'll prestage these servers a couple days before and on the night of the change window i'll script doupdate.cmd /skipdefs /seconly /autoreboot a few times until all is happy. next morning i'll review my log's and then i'll scrap the 2012r2 folder if I know there won't be a need for another pass the upcoming weekend. This has always worked perfectly for me, every single time. It's my tried and true method. Today is the first time i've ever heard of a problem. I send the command through automation software via a cmd shell.Behaves exactly like I remoted to the the box and called the .bat. This morning I get a call about when people log onto the box, it executes for them and then reboots. Had a guy just check it. He logs in, and doupdate.cmd kicks off just as I kicked it off that night with the exact flags. Anyone have any idea whats going on with this guy? This is the only one out of a hundred from this weekend that's doing this or has ever done this.