Sabkor

So for anyone else lurking on this thread, I've also gone back to my original setup of having the auto-logon. Using the code snippet that Lucid posted, I was able to get this working. Thanks again Lucid! Here's the code (VBS), for anyone interested: PLEASE NOTE: This code has only been tested during the deployment of Windows 7 64-bit, and was copy/pasted from my main script, which does other things as well, YMMV. Const HKEY_CLASSES_ROOT = &h80000000 Const HKEY_CURRENT_USER = &h80000001 Const HKEY_LOCAL_MACHINE = &h80000002 Const HKEY_USERS = &h80000003 Const HKEY_CURRENT_CONFIG= &h80000005 Const HKEY_DYN_DATA = &h80000006 sUsername = "My username" sPassword = "My password" sComputer = "My computer/domain name" ' You could also get the current computer name with the following: ' Set objNetwork = CreateObject("Wscript.Network") ' sComputer = objNetwork.ComputerName strRegKey = "Software\Microsoft\Windows NT\CurrentVersion\Winlogon\" Write64BitRegistry "REG_SZ", HKEY_LOCAL_MACHINE, strRegKey, "AutoAdminLogon", "1" Write64BitRegistry "REG_SZ", HKEY_LOCAL_MACHINE, strRegKey, "DefaultUserName", sUsername Write64BitRegistry "REG_SZ", HKEY_LOCAL_MACHINE, strRegKey, "DefaultDomainName", strComputer Write64BitRegistry "REG_SZ", HKEY_LOCAL_MACHINE, strRegKey, "DefaultPassword", sPassword Write64BitRegistry "REG_SZ", HKEY_LOCAL_MACHINE, strRegKey, "ForceAutoLogon", 1 Write64BitRegistry "REG_DWORD", HKEY_LOCAL_MACHINE, strRegKey, "DisableCAD", 1 Sub Write64BitRegistry (strRegType, strRootKey, strKey, strValueName, strValue) ' Attempts to write the supplied registry keys in a 32-bit wscript.exe process by using WMI. ' http://msdn.microsof...664(VS.85).aspx Dim objCtx, objLocator, objReg, intReturnCode Set objCtx = CreateObject("WbemScripting.SWbemNamedValueSet") objCtx.Add "__ProviderArchitecture", 64 Set objLocator = CreateObject("Wbemscripting.SWbemLocator") Set objReg = objLocator.ConnectServer("", "root\default", "", "", , , , objCtx).Get("StdRegProv") If Ucase(strRegType) = "KEY" Then intReturnCode = objReg.CreateKey(strRootKey,strKey) End If If Ucase(strRegType) = "REG_DWORD" Then intReturnCode = objReg.SetDWORDValue(strRootKey,strKey,strValueName,strValue) End If If Ucase(strRegType) = "REG_SZ" Then intReturnCode = objReg.SetStringValue(strRootKey,strKey,strValueName,strValue) End If If Ucase(strRegType) = "REG_EXPAND_SZ" Then intReturnCode = objReg.SetExpandedStringValue(strRootKey,strKey,strValueName,strValue) End If If Not intReturnCode = 0 Then 'Failed to set the registry entry End If End Sub

huh, thanks! Learn something new every day. It's funny too, I've posted this several places (even the official Microsoft forums) and noone even mentioned this. There's still something wrong though, either with SCCM or Windows 7 x64. According to their document here http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx, only certain registry keys are redirected. Neither the HKLM\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background (where the logon background value resides) or the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon keys are on that list as being redirected, so according to the document that means they should be shared. Not going to lose any sleep over it though, at least I have a workaround now.

The registry writing via WMI calls worked! Anyone able to explain or point me to a MS document on why? I wasn't aware that 32-bit registry editing tools would not work on a 64-bit system. Is the registry virtualized and redirected much like the Program Files and system32 folders? Now I'm going to go back and try my original VBS (setting up the auto-logon) with that new registry Sub as well.

Well, SCCM is *really* starting to annoy me. So I tested the background image thing, thought that'd work great. Created my own background image with the username password that they will need. Then the following happened: #1) Changed VBS script to create OEM registry key to tell Win7 to use my new background image and to copy the image to the correct location. Nothing worked. After investigation, it appears that even though I'm deploying a 64-bit OS, it's running a 32-bit version of CScript, as my file gets copied to the SysWOW64 folder, instead of system32. When deploying an application (which my script runs as an application deployment, to keep the VBS and JPG files together), I could not find a way to turn off 64-bit file redirection. #2) Changed VBS script to create OEM registry key and just copy the JPG to the D:\ drive, so I could put it in the right spot with another TS (using a command-line, where I can disable 64-bit redirection). Created another TS step to copy the file to the correct directory. This did not work, OSD failed with a file not found error. After investigation, found that although OSD says it's running a command-line, it's not really, and you can't run some commands without prefacing it with the command-line interpreter. #3) Left VBS script the same. Changed the command-line TS to run with 'cmd /c copy' and now it works. However, my login screen was still not modified. After investigation, my OEM registry key gets removed when the deployment completes. It's there after the command runs, but after the deployment completes successfully, it's not there, so my login screen modification never gets shown. ARGH! Why does Microsoft have to make something so easy into something so complex. I have no idea what's going on here, and am still looking for ideas on how to proceed.

No, we're not running any post-install scripts. This is done for 'loaner' laptops that are not on our domain. They are loaned out to faculty and staff from our library and as such, it's easier for them to have an auto-logon than to have the user remember a username/password for a laptop that they'll only be using for a day or two.

Sure, here are the two TSes that I've been trying with. One is just a regular TS x64.xml, the other a MDT TS x64-MDT.xml. In the TSes, package FVW00043 is a VBS that creates the registry keys, package FVW0004A is a REG IMPORT line. I tried both ways just to see what works. Neither does. As well, all of the reg export stuff near the end of the regular TS is just debugging, to try and see what happens with the keys.

I'm booting back into the OS. I have my registry steps as the very last steps of the Task Sequence, so the OS is up and running, it's installed a few applications, etc. I did some debugging by adding lines to the Task Sequence to dump the registry at various points, and my auto-logon registry keys are there throughout the entire process (even after reboots). However, after the Task Sequence ends, they are no longer there. That's why I'm assuming that SCCM is cleaning them up somehow. Someone (on another forum) posted that they believes this to be a problem with the OS that I'm deploying, Windows 7 x64, as they are having this exact issue with that OS too. (And yet, others seem to not have this issue, so perhaps they are not deploying a 64-bit OS?)

That's a pretty good idea, one of those obvious ones that takes a set of eyes that hasn't been staring at the problem for days. I've modified the Windows logon screen to include the credentials that they need to use to logon. Not as elegant as an auto-logon, but definitely works, and works now. Thanks!

I've been trying to get this to work too. I'm betting that if you login manually and check the registry, you'll find that none of your autologon values are there. I've been playing with this a lot as well. We have several laptops that are given out as loaners, are not on our domain, and are currently (through MDT LiteTouch) setup to autologon. I'm trying to replicate this with SCCM and am finding it quite difficult. What I've tried: - Setup a Task Sequence that creates the registry keys via a VBScript Problem: The keys are there after the script runs, but not after the OSD completes, even though the script is the last step in the OSD. Assumption: SCCM removes those registry keys as part of it's cleanup. - Setup a Task Sequence that creates a RunOnce key to import the registry keys Problem: Someone has to remember to login once after the deployment runs to get autologon working. I'm investigating other methods of doing this, but just feel like I'm getting in over my head, and there has to be someone who's tried this before. You and I can't be the only ones using SCCM that need the computer to autologon when SCCM is done. Anyone have any ideas?