AutoDomain Endpoint Encryption Deployment Script for “SafeBoot”
Download AutoDomain 5.53 From CTOGoneWild
NOTE – the latest version of the script has a slightly different UI from the one shown below – I’ll update it at some point in the future – Please see the manual included in the zip for details.
The “AutoDomain” project evolved over many months from a need to assist customers in deploying my companies encryption product, known then as “SafeBoot Device Encryption for PC’s” and now “McAfee Endpoint Encryption for PCs“. Though an extremely competent encryption tool with more options than you can think of, it can be cumbersome to deploy en mass. The most problematic item, and this is true with any full disk encryption tool, is knowing who the legitimate users of the PC are.
Windows doesn’t track this, and most IT departments have no better idea. It seems that people generally believe that ANYONE can log into any Windows PC in the average corporate environment – while this may seem to be true, the facts are that anyone can log into the network from any pc and once logged into the network once on any pc, that person will be able to login offline.
This is of course completely different from “anyone can login”, though, that’s what people expect. AutoDomain was designed to solve this by mining the local machine for cached accounts, and setting them as valid pre-boot users. Effectivly, if you’d ever used the machine in the past, when run the script would ensure you could continue using the machine in the future by assigning your Encryption user ID as a valid pre-boot user of that machine. Of course, no script ends up the way it was designed, and AutoDomain is no exception – it’s grown out of all proportion and includes such variable functionality as:
- Create users and machines on demand
- Auto-move machines and users into groups based on name, AD information etc
- Rename machines if needed, recover from the name already being in use
- Notify users by email that they have been assigned to machines
- Capture the users Windows credentials on assignment/creation and set up SSO
- Aut0-link users to connectors (and thus their AD counterparts)
- Correctly remediate from AutoBoot mode, set up permanent autoboot mode
- Check the current Windows user has a preboot countepart before uninstalling AutoDomain
- Check (and remediate) for competitive product and incompatible situations before activation
- Support auto-add new user on discovery (using ActiveInstaller)
- And of course many, many other features…
The current version of the script is pretty much self-sufficient. Although earlier versions needed tweaking for each environment, since the v5 version was released they are pretty much static, and mostly used packed as EXE’s (the source script is VBS). AutoDomain is built from a number of helper classes, so when you look at it, it may seem overwhelming. But, using something like PrimalScript, you can see that a good 4/5 of the script is included class modules which can be ignored (or reused for other scripts of your own).
The latest version of the script can be obtained from your McAfee consultant if you’re a customer, or from CTOGoneWild. There is no “official” support for this tool as it was designed to be customized to your environment, but most of the McAfee consultants are very knowledgeable about it, and most of our larger deployments end up using it.
Below is the legal note from the script , please remember you can’t call McAfee support about this tool – they simply don’t have the skill set to support it, BUT, the consultants do, and we acknowledge this is a vital tool for deployment so you’ll get as much help as you need from the Professional Services team.
Finally, if you enjoy this script and it saves you a whole bunch of time and effort, you might want to send me something from my Amazon Gift List? Thanks!
' LEGAL AND SUPPORT INFORMATION ' ============================= ' This script is the invention of Simon Hunt, an individual, and ' though I work for McAfee, this script is not supported by, or ' authorised by McAfee itself as a corporate entity. There is no ' official support for this script, though you can get assistance ' from the author at his discretion. You may also be able to get ' assistance through the community forums at ' http://community.mcafee.com. ' If you use this script in a mission-critical way, you may want ' to consider contacting McAfee And agreeing some professional ' services support, outside the terms of your normal technical ' support contract. ' McAfee will offer support for any McAfee specific API calls in ' this script, but, not the logic of the script itself.
Leave a comment
Who?
 | EVP Cyber Product Innovation for Mastercard. Formally the Chief Technology Officer for Intel Secure Home Gateways, CTO for McAfee Enterprise Endpoint, CTO McAfee Innovation team, and Founder/CTO SafeBoot Corp. |
Comments
 | Christopher Burgess on How not to implement smarthome… |
 | Mike on Is Encryption enough? Why just… |
 | Simon Hunt on Is Encryption enough? Why just… |
| Mike on Is Encryption enough? Why just… |
 | Stéphane Pautrel on New S.M.A.R.T Monitor Tool for… |
Simon Says - Musings of a Technology CTO 
A few comments to make this better.
1) In this statement above, I believe you meant AUTODOMAIN not AutoBoot. – Of course, no script ends up the way it was designed, and AutoBoot is no exception
2)Unwanted behavior report – What is the purpose of the IE connection to mcafee.com when autodomain.exe runs? Can you remove the IE connection to mcafee.com please?
3) Even after the connection to mcafee.com has terminated the IEPLORE.EXE continues to run until the autodomain.exe process terminates. I’ve even changed my autodomainlog file to text so why does IEXPLORE keep running?
4)Bug report – We had a device that had a drive that was compressed. The log file showed that it detected drive compression, attempted to uncompress and was unable to do so for some reason. The autodomain.exe process should terminate at this point but it doesn’t. It continued to contact the server, add machine and users, etc. The problem caused by not terminating the installation process during the compatibility check process was, the user connected to their home network to uncompress their drive in the evening and the machine contacted the server over the public network. It created a duplicate machine name and it did not add any users, probably because the synchronization process was interupted when the user connected to VPN.
5)Bug report – We use the clearkey option. Can you prevent the machine object from duplicating itself? Since the machine object and current users are added during the intial installation process, prior to the first reboot, the machine object is completely created. Upon reboot, the machine immediately contacts the server as soon as the tcp/ip stack becomes available, even before the user can logon. The problem of duplicate machine names, even if using clearkey, is that if the first full synchronization is interupted, it corrupts the machine object and it recreates a duplicate machine account appened with 000x. It seems like you should be downloading some of the server configuration that is downloaded to the client on the first full sync during the initial sync/creation of the install process. I’ve noticed that it depends on when the first full sync is interupted if it creates a new machine account on the next sync.
6)It seems like if I set the scm.ini file setting BootSynchDelay=7 that it kills the network for 7 minutes or until you log in and the EEPC Wizard fires off the autodomain.exe. I was unable to logon to VPN, for what seemed to be about 7 minutes. I need to some more testing. Is there a registry setting that BootSynchDelay= setting equates too so we can manually make an entry in the registry to allow users enough time to logon to VPN after rebooting when the install set has completed?
7) How about an option in the endpoint encryption manager to reset all to group configuration that would Exclude or Include (if unchecked) User Groups? I made a bad mistake and unchecked Exclude Users on a machine group with about 20 machines as I was removing and adding different User Groups which I wanted to apply to all the machines in that group. Since I unchecked Exclude Users it updated every machine in that group and removed the valid User Accounts. I had to do an Audit on each one and then add the users back onto the devices. That was not too fun, but a good learning lesson. Had an option been available to include User Groups but Exclude Users it would have accomplished what I wanted. So now I have to go into every machine and update the User Groups.
8) How about a GUI, with integrated autodomain manual help file, e.g. help pop-up for each Option, to configure the autodomain.ini and scm.ini files?
9) How about adding logged exit codes like most programs do that can be read from a file to determine if the software was installed or not and if there were any problems found or not during the installation process. e.g. install set lays files down and performs initial sync. Depending on what happens during the install process, produce a log file that shows good or bad. Your Install Sets created from the Admin Console when you choose the reboot option don’t work correctly. The install set prompts you to reboot 5 minutes before the first synchronization finishes and causes some bizarre effects if you reboot when it says its done and its not.
Thanks for coming up with the AutoDomain package. We are getting ready to deploy to 23,000+ laptops in the FS over the next couple of months.
1. Typo – thanks.
2. To display a nice logo in the IE window. Due to security in IE I can’t access a local file.
3. Because the script isn’t running in IE, it’s using it to throw output. I don’t actually want the user to have any control over the script so it’s not possible to close it without access to task manager. As to why we always open the window (but hide it), it’s to solve some bugs we found in the com API for IE, where the window would not open on demand any other way. It’s keeping it open because you set options which may require users to enter something (like their password).
4. I’ll look into that. I thought there was a cleanup after a failed decompress, but I might be wrong.
5. No sorry – The machine is always created by EEPC itself, we just pre-create a template machine for it to use if it agrees. The 0001 machine would have been created outside the scope of AutoDomain.
6. Not sure this is what you think it is – the delay just tells EEPC not to do anything, it does not have any affect on the network. No, there’s no registry key though related to this.
7. You can suggest it as an FMR to your McAfee rep, but this is not a McAfee site so it won’t go anywhere from here 😉
8. There’s a configure routine which does most of the heavy lifting, but as this is an admin tool it seems the hard work spent writing a gui would be better spent on items 1-7 😉 Feel free to write it though and publish it!
9. AutoD does not do the install though so I’m not sure what you are asking for here, also the client creates a full log file (sbclientlog.txt) which tells you everything about the last activity? Re the reboot warning, I guess this is because you set a long sync delay, and the script finishes and assumes as there’s no sync in progress that it’s already happened. I’ll see if there’s anything than can be done to neaten that up.
thanks for your detailed comments! you can use community.mcafee.com to have a more interactive discussion about AutoDomain than can be published here.
Re 4, the latest version does abort if compression fails to be resolved. Line 7801 etc for the check, and 7903 etc for the resolution after blnPlatformGood is false.
Version 6 looks like being quite a major revision of ‘Safeboot’ with lots taken out. What will change substantially after its improved integration with ePO? Is it too late to be worth considering many of your points on a long term basis?
Architecturally, v6 supports pluggable encryption providers so the main thrust will be to start taking advantage of hardware encryption methods, like the embedded crypto in Opal and other hard disks. This won’t really improve the security much, but will leverage investment in hardware and should be faster as well.
Dear Simon,
i need your help scripting part.
i want to enable local recovery option in all users through XML script.so if you have any idea about that please let me know.
Thanks,
Dipen Rana
Sorry Dipen, it can’t be done. Only a small subset of the EEM options are exposed to the scripting API for security reasons, and this isn’t one of them.
Good afternoon Simon,
I am in a bit of a pickle here and I hope you can help. We just upgraded our autodomain script to 5.25 after upgrading the MEE server to 5.2.3.5. I set all of the parameters in the autodomain.ini and tested very extensively. Everything worked famously during my testing period. We dicided to start testing in the general population of our company and things went a bit awry. Here is the issue, during testing of the autodomain script, it would ask for the users credentials 100% of the time. Now that it is being tested in the wild, 30-40% of the time the autodomain script is not asking for credentials. I reeled everythig in again and started to do more testing and I cannot reproduce the problem no matter what I do. The only difference is that I am sitting at my desk and some of the test users are on different subnets. I saw a post in McAfee Communities that you replied that a user may be rebooting too soon or the network connection may be dropping. I am certain that this is not the issue here. Can you provide any further insight as to why this is happening? I am going crazy, please help. Thanks.
looking at the log you sent via the forum, the user who you pointed out did not get prompted already existed. if you don’t have alwaysaskforpassword set to true, it will assume the user has already entered their password somewhere else, and won’t prompt them for it again.
start a thread on community.mcafee.com in the encryption : EEM forum, then people will be able to help you. The first thing they will ask for though is some evidence of the problem – like an autodomain log showing it happen.
Can the time out period for a user to enter their password be turned off so that if they are not at their desk when the install runs, they will come back to the asking them to enter their password?
You could turn it off by editing the code (getpassword routine), or you could set a very big number for it, like several hours.
The timeout is important in case the machine is unattended, or you deploy it with SMS etc.
We are getting ready for a large deployment of MEE 5.24. I downloaded the version of Autodomain 5.25, registered the executable and then go to the correct directory and execute autodomain.exe /configure. No configuration options are provided and the immediate results are as follows
MESSAGES
This script is finished. You can close this window, or it will close automatically in 10 seconds.
I’ve had success with previous versions of autodomain 5.2 but no longer have this version. Other than shell for professional services, any suggestions would be appreciated.
this is not really the place for tech support David, you’d be better off posting in the EEM Encryption forums of http://community.mcafee.com BUT, the answer to your question is you are using the wrong command line – you need to use cscript.exe autodomain5.25.vbs -configure. You can’t run the configure routine from the exe itself as it runs under PrimalHost.
You might also want to look at v5.5+, as I’m not really supporting the 5.2x version any more as it does not work well under W7, IE8 or x64.