Sigh, here we go again...
Began by creating a page for documenting our internal ainstall package program so thoughts can be jotted down.
Some things never change, and that is, Microsoft docs suck. Long on fluff, short on critical detail, long on repeating the same details over and over again.
Having fun trying to get distribution share created along with the dushare (dynamic updates) created today. Finally got what might be right, but then find the winnt (not winnt32) command doesn't undertstand the /dushare switch. Here's a tool for deploying an unattended version of XP but everything assumes you already have a win32 version of windows that you are installing from.
A helluva two days. Yesterday was a total loss, couldn't get an install to work using vmware. It would hang after the first phase of the copy to local hard drive, just before the longer copy involving the progress bar. Tried all manner of things. Only thing that worked was running winnt from a CD image. So today I said heck with it (for now) and grabbed a new computer out of a box (it's good to be in charge of computer distribution at times!) and set it up to be a test box. Now I have four systems with five monitors in my office. I guess a kvm switch would be nice but one's an old legacy unix workstation, the PC is dual head, etc, etc..
Well, the unattended install worked using the answer file, but the autologon did NOT work. I'm not sure exactly what that auto logon count key does for example, it never auto logged in once. The guirunonce crap seems to run when one first logs on (manually). Microsoft's kb q310584 has some instructions on autologon.
Also watched the technet session TNQ102-01, "Repackaging Applications to Support the Windows Installer Service." So far it looks like it will beat sysdiff, but I wonder how it handles app installers that require additional steps to be performed after a reboot. More info can be found on microsoft web page by doing a search for "Roadmap to Windows Installer Documentation". As usual, it was lacking in certain details. Like it said it's important to run the wininstaller on a machine separate from the target machine but doesn't say how and only demos it all on one machine. Ah, er, by mounting the drive and snapping the C$ share? By some other magic? There's more info on this on microsoft web site, article entitled Windows Installer Service Overview. As with most docs, it's more of a marketing feature-list fluff piece, short on detail of actual implementation.
(Wishing for something simple yet effective like .deb or .rpm packages right now...)
The dushare option in the answer file seems to have done squat, since there are 13 critical updates reported when I run windows updated after install. I did the duprepare step too, but I may have misunderstood it. Gotta read kb 312110 article to see if I missed something still.. ---- Arrgh, according to that doc, dushare doesn't work with installs started by winnt.exe, just winnt32.exe. Do you understand the stupidity of this? You can't install this OS properly unless an existing windows 32-bit OS is installed already. Cripes... I'm having a feeling that the autologon crap may also just work with "upgrades" as well.
Now I can understand why most people just give up and ghost shit...
I've also noticed that just a simple complete reference for all that can go in an answer file just doesn't exist. It's spread all over and you may find samples here and there. For example, doing a google search on dushare turns up precious few hits (maybe eventually it'll turn up THIS page :)
An all-nighter. I should do these more often. Get a lot done when no one is bugging me!
Wonderful, there is a deployment doc in the xp cd under support\tools\deploy.cab file. *NOW* I find the thing... But... upon further looking, it's lacking in many areas too... *BUT*, missing in the xp deploy.cab file but present in the w2k pro cd is a file called unattend.doc. Now *THAT* has complete docs on the unattend.txt file...
I tried ditching the encrypted local admim password and put it in as plain text, and it auto-logged in. Joy. I tested it by putting in the encrypted password string back in and it failed to logon again. Swell.
On the brighter note, it joined the domain using the account I set up that had these rights. It also did this without deleting the old computer account. A major win for us! Now to try to restrict that account from logging in and see if it still works.
ie branding seemed to work with our IEAK install -- kind of. Most urls you go to loops like mad and many pages don't load all the way. Hitting the security tab causes a crash in inetcpl.cpl. Need to have IEAK repackage this bad boy and try again.
According to chapter 4 of XP resource kit, you can at least apply service packs to distribution share using servicepack.exe program with -s param pointing to the i386 dir... Also, according to q296861, chaining hotfixes in one reboot is not a problem with XP as it was with w2k and NT. Only problem I see so far is that some hotfix files don't understand the -u -n -z flags :(
Set ProfilesDir = "%systemroot%\Profiles" in
[GuiUnattended] section so it matches what our NT
machines do and to get around the start menu not appearing during
install. Works well.
XP has some .adm policy template files in its %systemroot%\inf dir but I couldn't load the main one into NT's policy editor. XP will load ntconfig.pol file from netlogon dir and apply the registry settings, but the preferred method is via active directory policies. The ntconfig.pol policies are the first applied and AD stuff overrides them. Since we should migrate the Domain Controllers in May, policy editing should probably be put off.
Started mucking with Office XP install including updating administrative share with all service packs and updates. In working on this, I noticed when I logged in as a user, then logged out, logged in as administrator, when I attempted to log out, it threw a dialog box up asking for password of the user I had previously logged in as to update their profile!
On a later logon, I tried to load the ntuser.dat hive that the previous user was using (that was just logged out) and it said I couldn't, it was still open by another process!
Pretty pathetic...
I'm going to try to turn off ability to set offline caching on user home directory. Kind of a drag actually...
Working on Office XP install. Same package I made for Windows XP seems to work with NT so far. More details in the NT diary.
Also working through the various weird hotfix installers that don't follow the standard -u -n -z type flags for unattended install. Like, for example, Q318202 says you need to install via:
Q318202_MSXML20_x86_en.exe /q /c:"dahotfix.exe /q /n"
Wonderful, isn't it? Of course, you can't throw that into cmdlines.txt because that requires double quotes around the command line. :-(
22:30: Oh bloody hell, some change has stopped the install from joining the domain. And this happened on two different machine installs. Sigh... Good night...
Another all nighter. Can't get crap done during the work day.
ZDNET has an article listing five reasons why active directory sucks.
Pat and I started working on an updated ainstall for applications that should be a lot smarter than old method, attempt to reinstall on failure, deal with dependencies, etc... Should be real nice -- if it works!
Finally done getting Office XP to work under NT, a side distraction so I can at least get some of the faculty who teach Office, Office XP under NT working so they can start learning it even though we aren't quite ready for Windows XP. Had numerous problems getting it to install without rebooting or throwing a dialog box. Complete details in the Office XP notes down in the NT section.
Has it really been three months since I wrote in my diary? Well, loads of fun and trials going on. Tomorrow is active directory rollout day for starters. The unattended install of XP is coming along nicely, although I'm seriously looking at using RIS now (Remote Install Service) instead of the old fashioned dos boot disk with net drivers. This will require DHCP support (we don't use that now) along with a setup of the RIS service. I don't like dynamic IPs to clients so we'll use "reservations" (in Windows terminology) or basically, tie a MAC address to an IP so it's static. The big question however is what OS to run DHCP under, Windows, or Unix. I'd rather do UNIX because, truthfully, everything is nice and simple, a parseable text file with no hassles. DHCP on Windows is able to be manipulated on the cmd line via the netsh command. For example:
netsh Dhcp Server 10.20.30.51 Scope 10.20.30.0 Add reservedip 10.20.30.246 00062b281e29 "bumbox" "one gig box" "BOTH"
Also started using wininstall to package programs instead of sysdiff. If you are using sysdiff, throw it out. Wininstall rules.
Upgraded all domain controllers over weekend with no real problems. WE ARE NOW 100% ACTIVE DIRECTORY! (Should I really be this excited?) Now the real problems probably start! :)
Tried doing the "assigned" packages via msi files. If assigned via group policy to the computer configuration (hklm) section, it is supposed to install during the next reboot. Well, it didn't. Event logged showed "The installation source for this product is not available." A few things had to happen before it worked, after loads of research. q278472 was helpful and said to ensure the computer account had access. Did that, still no help. Drove me up the wall since it worked from a DC share, but not our main file server share on a member server. Since another KB article said that this doesn't work across forests due to kerberos authentication issues, I speculated that the member server may not have the proper kerberos setup to deal with this. So on a hunch, I dropped the member server from the domain and re-added it. What do you know, it worked. Now, however, I wonder if a simple reboot would have accomplished the same thing. That member server hadn't been rebooted since the DCes were converted over.
What a pita weekend this has been. Pat had reported last week that a few test machines he installed didn't automatically join the domain using the install account we set up for that purpose. But it worked fine on the test machine I had been using, everytime. So Saturday I went to do my own test install and sure enough, wouldn't join. I pulled my hair out for two days trying to figure out what was different. Turns out, the containers and OUs themselves have to have certain ACL perms to be able to create a machine account.
So far, test machine didn't auto join computer account already in an OU. I mucked with it a bit and was able to get it to join through control panel using the install account, but only after I did a "netdom add machinename /domain:x.dtcc.edu /userd:installacct /passwordd:installpswd". It threw it in general computer container. Now I'm trying to manually create it in proper OU first, via the new/computer right-click menu from that OU and specifying the installaccount in the dialog box that says who can join it. If that works, we'll see if we can get it to join default computer container if no acct exists... (later...) Yup, that works. Now to try to pre-slug the OU in the unattend.txt file and see if it creates on its own without having to manually GUI it in AD U&C (which would be a hassle with thousands of computer accounts...)
Finally... adding the OU info to the unattend.txt file and if the admin password chosen to add computer accounts has correct access to the OU to do so, it actually works! A useful tool is netdom, for example, "netdom query /domain:x.x.x /userd:installid /passwordd:installpswd ou" will show what OUs the specified user has permissions to create computer accounts in.
One thing we found out was the encrypt passwords in unattend.txt files are all but useless. There are two places you'd want to do it, for the local admin account, and the account that has rights to add the machine to the domain. Well, if you do the local admin account, it won't do an autologon after install. Verified by a Microsoft kb article. And the one to add workstation to domain just plain ole doesn't work. The docs talk about a hashpwd.exe command to generate this one, but it's only available in the OEM preinstall SDK, which seems to be unobtainable. It isn't in Technet DVDs, and it's not in MSDN DVDs.
Loads more fun, including learning more than I ever wanted to know about wininstall. You have to be real careful in building your .msi files. If there are files missing in there when the user goes to run the app, it will throw up a "configuring software" box and then want access to the install share. It will do this on every run and for large packages, can be quite time consuming. So I later determined that it is trying to repair the missing file. Now, if you deploy these via group policy to the machine, then the repair feature isn't there so this isn't a problem. But if you install from command line, it is, and I found no way to turn it off. So to fix the package, it's a tedious process. Go into local group policy (gpedit.msc) and find the Windows Installer settings under Windows Component in Machine Config. There's an option for logging. Turn that on (default settings OK), and then rerun the app as the user. It will log to syslog, ah, er, event log, what files are missing. You need to note them and go in and edit the msi file and fix or remove the references. Once you get them all, all will work ok.
Last weekend, I hacked at managing user accounts via ADSI. Another nightmare. I haven't found a good book or reference either. I tell you first thing to watch out for. A lot of the ADSI scripting books are for old NT 4 domains. There are two methods for banging at accounts, one with WinNT:// and one with LDAP://. WinNT is for use on NT domain controllers. While it will work on an AD system, it will be limited to what it can do and read. It's ignorant about OUs for example. Hopefully I'll post some of my scripts later.
Hacking at ADSI still. User accounts must be generated by Monday morning. Gonna be a long weekend. Here's a good ADSI reference and VBScript Reference.
Yippee, I can have people log on using their e-mail address (user@college.dtcc.edu) instead of the domain address (ncco.dtcc.edu). I tried to get authorization to name our domain college.dtcc.edu since we will also be hosting e-mail for the entire college, but the DNS guy didn't want to give us that DNS name, so I picked ncco.dtcc.edu (our county abbreviated name). So using a UPN suffix and parking their real e-mail address into userPrincipalName, I can have them be able to log on and authenticate using their e-mail address.
Been having loads of fun, and no time to write to my diary. Sigh... This week sees the release of XP SP1, and IE SP1. One good, one bad. Why? Well, XP SP1 rocks because it's easy to "slip stream" it into your distribution share. No need to apply it after an install, it's PART of the install. Just extract it to a directory, then go into update folder and run (example):
update /s:n:\setupxp
where n: is the drive of your dist share and setupxp is the dir where the distribution is (the parent of its i386 directory). Works like a champ. Currently testing to see if it will auto-detect the hardware in a Dell Gx260, since we had to add drivers to the unattend.txt file to get those to load before.
IE sp1 is a different story. Even though IE 6 is part of XP install, doesn't look like it can be slip streamed into the distribution share. :( Microsoft wants you to use IEAK. I hate IEAK. Why bother with IEAKs bastardized method of enforcing restrictions when you have GPOs which are much cleaner? At least I could force the small net launcher to download the entire dir via the command:
x:\path\to\ie6setup.exe /c::"ie6wzd.exe /d /s:""E#"
(later...) Hey, pleasant surprise.. ie sp1 is part of xp sp1 and hence is slipstreamed automatically into the install. SWEET. The latest msn messenger is also in. I also went to windows update site and it didn't list any critcal updates (that should last a few days hopefully).
On a sadder note, my Dell GX260 didn't get its hardware detected by a slipstreamed XP SP1, so it's back to the unattend.txt hack. I guess I should take a moment to document it.
http://www.justinwojas.com/bootcd.htm
Main XP Unattended Install Doc Page