RogueSpear

Another option for this scenario that involved support is create a compiled AutoIt script that creates the account. You could run the .exe file during the install, include it on a distro CD, or just make it available for download on your support page for customers to install in the event that they need support. A slightly more complex method would be to make a VBscript that is signed and encrypted. The AutoIt executable method would probably be easier to make and would be more elegant in execution. The downside is that I don't know what sort of security is implemented in compiled AutoIt scripts, so I don't know how hard it would be for someone to decrypt it and obtain the password. My guess is that while it's not a trivial thing to do, it probably doesn't live up to NSA/DoD standards either. If the account is for authentication to facilitate remote desktop, DameWare, etc. then presumably they would have to have Internet access for that sort of support. If they're bringing the computer in to a service center for support, simply tell them that they need to run the file prior to bringing it in. Or you could just make it a silent part of your general installation routine. EDIT: In thinking this over, I suppose it would be possible for a keyboard logger to intercept the password when the script executes. Something to think about I guess.

Actually that thread was not what I was referring to, but nonetheless what I do does in fact place the password in the registry in plain text. I don't think that this is that big of a deal however since when the install is completed, those registry entries are cleared out. I used to be a major security freak myself and would never have considered this to be an acceptable thing to do. But that was in the past. Look at your environment and take practical measures. Spending hour after hour trying to secure something that has little to no chance of actually being compromised is really a waste of time. Unless you are mandated by law to take certain measures (some government agencies, HIPPA, etc) I would step back and look at things, then re-evaluate.

@eyeball, just click the link in my sig for the Script Pack. It's all in there. @cluberti, I don't know if you've checked it out yet or not, but I managed to work in that set speed and duplex routine that you found over at Code Comments. I had to change it's detection routine a little bit though as not all NICs write a full ComponentID to the registry. Still works great though and I've even added a few more NICs to it.

@cluberti, it's something I've suggested a couple of times previously, but a general lack of interest pretty much stopped it in it's tracks. I put together my script pack with the intention and hope that the thread might become such a repository. Most of the common unattended things people would want to implement with VBscript can be found in there. If it's not in there specifically, chances are that there's enough code examples that someone could adapt bits and pieces from my scripts to do whatever it is that they want. And I made the entire thing extensible so that people can throw in whatever they like with the suggestion that they post their own scripts for others to see. So far it doesn't seem to be taking off at all. I mean people are downloading it enough, but there hasn't been anything in the way of new contributions.

I always set AutoLogon entries at cmdlines in a VBscript. Some other food for thought: you can also rename the Guest account and strip away the description, create a fake Administrator account with the default description and make it a member of the Guests group. And here's a story to start your day off with. I always delete the local admin account from my installs as we've talked about in here. Well one day, someone in a senior level position decided he was a computer expert. So he thinks that unjoining a computer from a domain is somehow going to fix it. Soooo.. no domain membership, no local accounts = neutered computer. Of course this was not his fault. Somehow it was a mistake of the IT department.

I don't know about the UK, but here in the states upload speed is almost always crippled. The idea here is that your ISP does not want you to be hosting anything. So they give you enough speed for VoIP, video conferencing and the like. If you want a fat upstream pipe you're going to have to pay up. Like I said, this is how it is in the states, but I don't see any reason for it to be much different in the UK.

By default, Symantec blocks NetBIOS. Check your rules and makes sure that the blocking rules for default NetBIOS, SMB, etc. are either disable or do not apply to your subnet.

One little anomoly that I've noticed is that if you disable default administrative shares and then later enable sharing a drive from the root, when you reboot that computer the share will be gone. I don't know if this is a bug or if it's by design. One footnote: this is in workgroup mode, not domain mode.

I've always used nircmd.exe to change the screen resolution instead of 1365VidChng.exe. Now I know why nircmd has always worked It works from cmdlines.txt too.

It's possible that if you include AutoLogon entries in your WINNT.SIF that the SIF file instructions are applied after cmdlines.txt is processed. I don't have any AutoLogon information in my WINNT.SIF file and it all works every time for me. As far as defragmenting the hard drive goes, if you would prefer to not have your unattended install defrag the drive, just don't put the script on your CD. That way cmdlines.vbs will not schedule a RunOnceEx entry for it.

Actually the 4096 limit only applies to OemPnPDriversPath in WINNT.SIF, not to the registry entry created by SetDevicePath.exe. Instead of having a 4KB limit (WINNT.SIF), it has a 32KB limit. Also, SetDevicePath.exe prepends it's registry entry with %systemroot%\inf. So you're completely covered after it's use.

Look in the AutoIt help file under "Macros" and you'll see that %ProgramFiles% can be expressed as @ProgramFilesDir.

Call it prejudice, call it whatever you like. But the fact remains that I, and many others as well, have more trust in open source software. I'm not calling authors of closed source software untrustworthy, but I'd be willing to bet most software developers are not nearly as accessible as nuhi either.

The subroutine that installs Student I made quite some time ago and it's worked ever since. I really just included it as an example of how to use AutoItX.dll within a VBscript. On order for the script to work, and this is actually mentioned at the top of the script itself, you must have AutoItX.dll registered with the OS. Looking at the code you posted, the variable strOEM points to the \OEM directory on the CD/DVD. So if you're looking for the .7z file on %systemdrive% it's not going to work. This was actually kind of by design since the routine was made to install Streets & Trips. There's no sense in copying over an 800+ MB .7z file from the DVD to %systemDrive% when you can just decompress it straight from the DVD. And I figured that for RIS installations, you would be better served pushing Streets via group policy. If you are always going to copy 131_MSVM.7z to the %systemdrive%, then replace the variable strOEM with sysdrv.

Perhaps I didn't explain clearly enough. I perform a standard Method 2 during setup and then run my KtD script during RunOnceEx. I only mentioned how I used the KtD post setup on my wife's laptop because I thought it was a nice side benefit to be able to "retrofit" an existing install with added driver support. As far as Vista goes.. I'll worry about that later. Much later in fact. At my main job and at all of my client sites, I plan to keep XP for years to come. It does absolutely everything needed and then some. I've played with Vista for a little while now and to me it's not a whole lot more than a cosmetic makeover.

Well I can tell you that my method works perfect and it's pretty simple. I went through my building at work this week rounding up every single USB/FireWire/PCMCIA device I could get my hands on and everything installed like a charm.

I would caution against the CISSP. It requires a lot of studying about things you're not likely to need in real world environments. The luster of that certification is starting to dull as well. It's very expensive to take and then if you do somehow pass it, you need to make it a part time job getting credits for recert or study once again for the exam. My friend who I consult with got his CISSP a couple of years ago and his main preperation was the Shon Harris DVD set. I've watched them as well and can tell you that they're incredible. So if you do decide that this is what you want to go for, I'd recommend her DVDs. I spend a few years chasing down certifications, studying and so on. And I have a few of the CompTIA certs and a couple of the Microsoft certs. Overall I found it to be a waste of time. You're better off spending any free time you have going out and getting some real world experience. Even if that means doing some volunteer work someplace. What you learn through doing is much more valuble than what you learn through chasing certs. Remember, the people who put out these exams (Microsoft, Cisco, etc) often are not so much concerned with the right way of doing things, but rather their way of doing things. When chosing a cert, try to get some that are really recognized and standard like CCNA. CompTIA is nice because theirs never expire, but honestly just about anyone can get A+ or Network+ with a week or two of hitting the books.

I've put in options to delete content from the Start Menu and to change the NTFS security permissions to user defined folders with Programs, but I'm not doing anything with the sort order at all. I think one byproduct of deleting some folders in the Start Menu is that the sort order gets all out of whack.

Yea GunSmokingMan always puts out nice clean code. It doesn't always look pretty in posts because of the way CODE tags handle indentations, but put it in PrimalScript or something similar and it looks great. Logical and easy to follow.

Perhaps you could send me a PM in your native language and I could try running it through BabelFish or something. I'm not trying to make fun of you when I say this, but I can hardly figure out what you are saying most of the time. And it's frustrating because it's probably something easy to fix, but I'm just not getting the details that I need.

You may want to consult the help file and do some searches on Microsoft's web site to get all the information on that particular option. I really think that either it or my previous suggestion is what you're going to need in order to get the settings to take on your NIC.

04/12/2006 The scripts have all been removed from this thread as they have turned into a project of their own. They still work with RIS though, so if you like them and use them, they can be found here. This is likely the last update I will make to the guide. Everything described here can be done automatically, more easily, and with far less chance for error using either my utility AutoRIS or Fencer128's utility RISult. So at this point, the guide is really here for those who like to get into the nuts and bolts of things.

From what I'm reading in ref.chm you may want to try using the NetCardAddress entry as follows: [params.Adapter1] NetCardAddress=MAC Address In the example that they give in the help file, the MAC address is solid with no dashes and it's preceded by "0x" (without the quotes). I'm not sure why as they make no effort to explain it. Also, it says that if you use NetCardAddress, INFID is ignored. I think my initial thought may be correct as well considering this entry from the help file: It would seem that if the FireWire NIC is detected first, it will get the settings. To test my theory out you could always do the install and then look at the network settings for the 1394NIC.

Update 04112006 Now supports wildcard for decompressing archives to %SystemDrive% and %SystemRoot%. I found this made it easier for me with all of the different setups I have to maintain. As an example, you could have 000_WinDir.7z that you use in all installations, but then also have 000_WinDir-Work.7z and 000_WinDir-Home.7z for differing installs. With support for wildcards you can now just pick and choose as many or few as you want to include in your source.

You may want to see if the printer was published to Active Directory. If it was, Active Directory printer pruning will delete it after some time (I forget the default time period).