9 Replies Latest reply on Nov 22, 2010 7:14 AM by SafeBoot

    AutoDomain Migration Deployment Issue

      (I use the word safeboot and EEM interchangeably)

      We currently have 6000+ machines (Windows XP) with safeboot (local accounts) installed.  When we are attempting to migrate to Windows 7 with domain based cached accounts, We are averaging about 50% failure ratio due to safeboot.  Can someone help us understand how to improve our process?


      1.  We currently use the autodomain script, when I called Mcafee they stated that they will not support the script


      Our Core Problem(s):


      We deploy laptops out of centralized area, we image the laptops then in the past we installed safeboot and preped the laptops for the user.  When we switched to the new version of safeboot, it had a requirement that the user be logged in PRIOR to installing safeboot.  This is not possible in our configuration and makes no sense from a deployment standpoint. 





      1.      What is the recommended way to deploy safeboot in a supported method that will support 6000+ users in a specific AD container or security group?

      2.      Why is our only option an unsupported tool?

      3.      How do we fix this?



      Finial Thoughts:


      It feels like a catch 22, we need the auto domain tool due to our size, but the funny (or not funny for us, part is that this auto domain tool is not supported.)  This game of paying an extra cost just to use the product seems slightly ridiculous.  Time to start evaluating other products :done venting:


      Thanks in advance for helping!


        • 1. Re: AutoDomain Migration Deployment Issue

          EEPC does not care how many users you have in an ad container - it only cares how many you try to assign to it - try to assign JUST the users who need to use, or have used the machine, not everyone - that's bad security and also will add load you simply don't need.


          You should indeed use Autodomain - it will provision JUST the users who are already using each device to the machine.


          I don't understand


          When we switched to the new version of safeboot, it had a requirement that the user be logged in PRIOR to installing safeboot. 


          No version of SafeBoot has had that requirement - they can all be deployed via SMS, background task etc - there's never been a requirement that someone had to be logged in?


          Autodomain is an example script showing how to use the API to do customized work - it's not supported because a lot of customers heavily edit the script to their own requirements. You can of course get a lot of advice here though.

          • 2. Re: AutoDomain Migration Deployment Issue

            Thanks, Let me explain a little,  It might clear up misunderstanding if I am misunderstanding something.


            We image laptops in a warehouse,  The warehouse tech uses a local admin account, or his AD account.  At the end of prepping the laptop, safeboot is installed.  If auto domain runs at this point, it will not gather the SAM or GUID of the actual user that is going to be using the laptop as they have not logged in yet,  it will only collect the warehouse tech's account info.

            • 3. Re: AutoDomain Migration Deployment Issue

              why not put the warehouse users on the skip list then, and leave the machine in autoboot mode with skipusers=true and runonlogon=true? Then once a "real" user logs in, AD will collect their details provision them and then remove the autoboot user thus securing and provisioning the system?


              because it will skip the warehouse users, the machine will not "activate" the pre-boot at that time.



              Message was edited by: SafeBoot on 11/13/10 1:01:33 PM EST
              • 4. Re: AutoDomain Migration Deployment Issue

                Interesting,  That might just work!  Two questions for you.


                1.  I am not an expert on autodomain by any stretch of the imagination, is there a guide floating around?

                2.  Our autodomain.vbs is showing version 1.0 but I am not sure if it was hacked and chopped together or modified,  is it safe to assume I can take my current config, and just swap autodomain.vbs for the new version and be good to go, or do I need to migrate things to the new version?



                • 5. Re: AutoDomain Migration Deployment Issue

                  The current zip comes with a manual ?


                  Version 1? That's for sure a home-brew invention. Current published version is 5.58 I believe. Whether you can move the configs over really depends on exactly what version you really have. Most options are compatible from around 4.2 onwards though.

                  • 6. Re: AutoDomain Migration Deployment Issue

                    We updated our autodomain to 5.58 and moved our .ini over to the new install.  Few questions:


                    1.  We do not see "skipusers=true" in our ini but we see "skipusers=|NAME1|,|NAME2|

                    2.  How do we setup runonlogon=true?  We do not see that option in the ini but it looks like a command line,  how so we specify this command option?

                    • 7. Re: AutoDomain Migration Deployment Issue

                      1. Yes, it's the list of users to skip?

                      2. It's an ini file - you just put the option you want in the file, remembering that any line starting with a ";" is ignored (it's a comment).

                      • 8. Re: AutoDomain Migration Deployment Issue

                        Thanks,  We are close but something is still strange.  We have it working "sometimes" but not always.  When it attempts to add the machine to the safeboot server sometimes it takes 30 sec and works, but other times it takes 10+ min and creates duplicate machine names.  We verified that we have the .inf to have the database indexing, we don't think its a firewall issue as 5556 and 5555 are open, the servers 8 cpus are almost idle with no more then 7 connections every few minutes,  any ideas?

                        • 9. Re: AutoDomain Migration Deployment Issue

                          the log file will tell you exactly what's going on - usually it's because you're not running it as part of the install set though - AD won't create "duplicates" - it only creates the actual machine .To get a duplicate means the machine tried to activate but it was aborted, either because the user rebooted or because something happened to break the connection with the DBServer.


                          By comparing the Autodomain log and the client log you can tell what went on.