Jump to content


  • 0
Sumixam

Setting up Autologin at the end of SCCM OSD

Question

I have a Task Sequence in SCCM that is deploying my test image just fine, so all the basics work. Now I am trying to add in the steps unique to our environment.

 

The first thing I need to do is to set the machine up to restart and auto log in when the TS completes. The restart works fine, but the auto login doesn't

 

I used the autologin example from this post ("How can I capture Windows 7") as a model but I cannot get it to work.

 

Right now I have the following 2 steps at the very end of my Task Sequence:

1. Run the autologin package (from the post) that imports the Registry keys

2. Restart the computer (I changed this to manually run Shutdown as I know the "Restart Computer" task in MDT sets the machine up to autologin as the local admin, better safe than sorry)

 

When it runs I get a quick flash of an error about interactive logins are not enabled (or something similar, it flashes quickly) and then the system reboots. When it comes up I get the Crtl-Alt-Del to login screen. When I do CAD my user account is set to log in but I have to provide the password. The password is correct in the REG file, so that isn't it.

 

Has anyone gotten this to work? Am I in so deep that I'm missing something obvious?

 

Thanks

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

change the restart computer step back to the way it was, does it work then ?

the task sequence i posted didnt use mdt integration, are you using it ?

Share this post


Link to post
Share on other sites

  • 0

No, it doesn't with either restart option.

Yes, I'm using MDT integration.

 

I've been reading that the GINA used by OSD blocks a lot of things and I'm wondering if this may be one of the things it just won't allow. In essence, I'm breaking the Task Sequence before it completes. Granted my steps are the very last things in the TS, but they still happen during the processing of the TS.

Share this post


Link to post
Share on other sites

  • 0

 

Has anyone gotten this to work? Am I in so deep that I'm missing something obvious?

 

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?

Share this post


Link to post
Share on other sites

  • 0

Why do you need it to auto-logon as part of the deployment process? Can you create a separate package, have that targeted to a collection, and then just plop the newly imaged machine into that collection?

 

Either that, or look at requiring people to log on? You could always have a message display when someone presses CTRL+ALT+DEL, or else just tweak the background image on the screen. Just a thought...

Share this post


Link to post
Share on other sites

  • 0

Why do you need it to auto-logon as part of the deployment process? Can you create a separate package, have that targeted to a collection, and then just plop the newly imaged machine into that collection?

 

Either that, or look at requiring people to log on? You could always have a message display when someone presses CTRL+ALT+DEL, or else just tweak the background image on the screen. Just a thought...

 

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!

Share this post


Link to post
Share on other sites

  • 0

@lucid FYI, We use the autologon once the image and applications are deployed, there are some things we simply cannot do whilst deploying the image, we use a series of post install scripts to take care of these functions. Things like setting screen resolutions for widescreen laptops, forcing wireless networks to connect to a network, then various other things. It becomes very useful to be able to auto boot to desktop

 

@sabkor in your restart are you coming back into the boot os or boot pe mode?

Share this post


Link to post
Share on other sites

  • 0

@sabkor in your restart are you coming back into the boot os or boot pe mode?

 

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?)

Share this post


Link to post
Share on other sites

  • 0

yeah x64 is a bit nitpicky i find also... some of my scripts dont operate as expected always either...

 

i'll buildup a new 64bit TS today/tommorrow and test again.... can you export your TS (censor it) and send it over? give us something more to work with :-)

Share this post


Link to post
Share on other sites

  • 0

yeah x64 is a bit nitpicky i find also... some of my scripts dont operate as expected always either...

 

i'll buildup a new 64bit TS today/tommorrow and test again.... can you export your TS (censor it) and send it over? give us something more to work with :-)

 

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.

Share this post


Link to post
Share on other sites

  • 0

Just tossing out my two cents... If you're running post-install scripts after you logged in, you should be able to convert them to a script that can be run by the OSD process. We customize a ton of settings in the OS via VBScript (just make your script into a package and add it to the tail end of your OS TS), so you may want to think about tackling the issue from that direction...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...



×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.