Did get rsh to the NT box to work. Turns out you have to define Administrator in the service control panel for the rshd service, before it could execute many net user commands.
Luke will be coding a UNIX interface to allow our various maintenance programs to pipe commands to the NT server, mainly for account maintenance...
This means we can use full facilities of a PDC on NT whilst still giving us the flexibility and consistency of Samba. Samba will use the PDC to authenticate users. However, since all password operations will be synced, the one acct/one password solution still doable.
Removed the samba plain passwords patch from the update.inf file for service pack 3 to see if Samba using a PDC to authenticate works this way. It worked, so no need to add that patch anymore. Better to not allow unencrypted passwords to leak out...
Samba team develops a fix for hanging roving profiles today. Tested it, it works fine. (add max mux = 50 in global section)
Added LMHOSTS file to $OEM$\$$\system32\drivers\etc directory so PDC can be found during unattended install. Still need to confirm that using SYSDIFF to generate the $$ directory won't overwrite stuff previously placed in there. If so, we need to make LMHOSTS part of the diff output instead.
Default directory permissions after running C2 seem way too wide open.
Question: If roving profiles are stored on UNIX, can user edit the ntuser.dat registry file using registry editing tools, park it back on UNIX, then compromise desktop security after logging in again?
Registry entries that will be edited are written to a .inf file in the $oem$ directory. Possible to edit this value directly.
The art of creating the sysdiff method will be hairy since any changes to that output will require a new snapshot and diff be created. I decided to create a "sysdiff page to keep tract of it.
During initial test of applying sysdiff during install, the system hung after it got to (what I think) installing SP3. Possibly hung at the rundll32 command added to Cmdlines.txt by sysdiff. Will test by getting rid of that line...
Later found that the rundll32 command was hanging. I reinstalled and ran this command manually. It hung. Tried editing various items out of the sysdiff.inf. Found that any INI edits would cause the program to go into an infinite CPU loop. Sigh... registry edits appeared to work OK. Am trying to resnapshot and rediff it, then use /apply to apply.
After screwing with it all day I found that...
Will come back to sysdiff later. Next steps to explore are:
Weird occurence. During an unintended install, network adapter failed to be detected. Re-installing it with no changes, and it worked.
Sigh, Microsoft's web site has been down all day. Yet another hacker attack, I bet. Absolutely amazing that they can't keep their damn servers up, yet expect the world to rely on NT servers for mission critical work... :-(
Was able to get the remote policies working without a hitch. One of the few things that have gone right in this task!
Finally got it and learned it couldn't work against office distribution just copied from CD to server. Had to do an administrative setup (setup /a). Did that and played with the "NIW" some.
Working on finding a way to run program installs from server without having to have the program distribution copied to local PC and installed from there. To do this requires connection to a share (hence password). Am making a UNIX and NT account to deal with this issue. It will be used to map shares from $OEM$\Cmdlines.txt and app installs run from that share. The actual command to do the install(s) will be in apps.cmd and executed via "cmd /c apps.cmd"
Office should auto-install now. Still need to test it since it bombed (due to a permission problem on the off97 share). The office policy template applied to ntuser.pol in netlogon share works well. Personal Folder had to be set to f:\ else it gets cached to C: and during logoff, documents are copied back to the profile server. Could be painful!
Should see if we can set the network drive to a var and use that in some of these areas in case F: is not available on a PC.
Need to test more policies, including parking "actors" somewhere (configurable by policy) in case people want to change the damn helpers!
ZAK docs talk about a program (con2prt?) that allows defining printers via cmdline instead of wizard. Cool, need to check it out.
Added acls.cmd to processing, and some C2 stuff (like changing boot.ini file). Test run failed to run office setup. I put forward slashes in pathnames in cmdlines.txt file for the run commands. Damn.
The cacls commands in acls.cmd change perms on entire disk drive, including the temporary files. May not be a big deal, but must slow things down. Probably can get around this with the RunOnce key settings.
Arrgh, failed again. Also, the boot.ini edit doesn't work. NT must reset this file before the final reboot. No idea why office 97 setup didn't run. The share was never touched. Perhaps networking isn't turned on at this point.
Ah, true. You can do a "net use" out of Cmdines.txt. Need to set up the RunOnce registry entry and do net commands that way.
Results of first "run once" test:
Tried inserting the commands:
I guess it's possible that some registry is being updated from ntconfig.pol during the logout that might make a difference. Will hopefully test this out tomorrow by doing "RunOnce" twice or something... :-(
On a more positive note, Luke has finished writing "ntrsh" which will connect to NT server's rshd port and send it commands from stdin. This will prevent having to send commands like "rsh ntbox net computer add username password" to the box which could be seen in a ps display.
Luke will now work on coding a modified passwd program that will change the password in NIS as well as NT server.
Arrggh... Autoadmin login will NOT work if the DontDisplayLastUserName key is set to 1. URGE TO KILL!
Stuff I need to work on now includes tuning security in the acls.cmd file shipped with ZAK, Netscape, hacking Manage to generate accounts on NT, and on and on....
IE2, that ships with NT, won't run in the restricted acls set by ZAK. Need to loosen it up, or install a different browser.
But for now, I need a break... These pages are going dormant for a week or so...
Also need to get a service release for Office 97 but www.microsoft.com is down, as usual.
Heard yesterday that we've finally ordered a site license for Columbia's Kermit 95, which should be arriving any day now. Am planning on trying to get that to auto-install into the mix. As is now tradition, a web page will document kermit 95 install experiences! :)
Down to the wire. Need to create a custom config file for each station that will include different stuff we need to install at each station based on its location, like printers, apps, menu entries, etc...
Propose making a separate config file for each station name with syntax similar to:
printer laser265 printer laser273 app office97 app acad14Basically, two tokens per line, one keyword, one value, then parse it during install with a command like...
for /f "tokens=2*" %a in ('findstr /b printer configfile') do pinstall %a
In above case, "pinstall" could be a small batch file to /apply the correct sysdiff file for that specified printer.
Recently have added Netscape and Adobe Acrobat to install. Today added timeserv files to automatically sync up clocks on workstations to our ntp servers. This requires parking timeserv.dll and .exe in %systemroot%\system32 and timeserv.ini in %systemroot%. Edit file to include Type=ntp and NTPserver=138.123.84.240. These files were parked in the $oem$\$$ directory structure.
Also had to add the following commands to worker.cmd:
Anyway, a security flaw detailed in KB article 126713 needs to be applied to our default instsalls.
Idiots... I hate Microsoft at times...
Damn ZAK hides all files by default. Don't get the point since explorer can be told to show all files. Am going to take that out of the unattended install script. Seems silly anyway, and if this is a problem, it may be a problem elsewhere as well...
Had some trouble getting the BDC to contact the PDC during install until I put an entry in the LMHOSTS file like this:
138.123.68.236 fruitcake #PRE #DOM:WEAVE(weave is just the test domain name I am using).
A bit tricky to do during an install. You have to import an LMHOSTS file from another location -- probably a floppy or create it with notepad by right-clicking in open window and making the file.
Once they are both up, they swapped info back and forth easily. I created an account on the BDC and it showed on the PDC.
I may park the BDC on net 64 to load balance and keep the net going if net 68 goes down at the router. At Wilmington, put one DC on 84, the other on 76.
At least this all makes reboots and stuff easier. Just promote a BDC to PDC in Server Manger, shut the old PDC down, work on it, bring it back up and re-promote it back to PDC.
Can also set up a one or two way trust with other domains. For example, if another campus wanted to authenticate user our user base, they could trust our domain but not visa-versa. Meaning anyone on our domain can log in anywhere, but their domain local users would not be trusted on ours.
Would allow other campuses to authenticate students via our Domain Controllers but not put us at risk from their systems.
With that in mind, we probably should go with a separate domain controller for students and then local staff. Maybe over the summer. Then you'd pick your domain during login time.
Beats the living shit out of NIS on UNIX.
LINUX can be set up to do all authentication via NT apparently. Would be nice to do that on DG/UX down the road somehow. Can't be that hard. Replace login, ftpd, smbd. Only bitcher would be pc-interface. Hmm, can do that too if need be since it has a hook for login authentication! :)
This is not 100% desirable. Ideally, the user saved IMAP dir, roving profiles, etc, should be at one location. Oh well, until we get a faster WAN, this will have to do.
Transfering PDC to new unit and renaming it seems to have worked. Still
need to do the %localhost% trick above though.
Also began to re-install Pumpkin, using the steps outlined in the bronx
install notes as a guide.
The env trick worked for the profile path, but not home directory. Then tried to unmap the home drive letter and map it manually. This kind of worked, but the system %homeshare% was still set invalid.
Finally decided to use the unregistered domain name "thiscampus" in the user profile and define this name in the client's LMHOSTS file. This workes like a champ! Each campus will have its own separate unattended install directory anyway, so we can just code the LMHOSTS file as appropriate for each location so "thiscampus" points to the closest local server.
Even with that, I still decided to code a separate env var (named %homebox%) in each system so it can be used during the login script phase. This gives the user a more palatable "My computer" display. They will know the true host name that is being mapped.
Fixed some script errors in ainstall.bat. Also looked into Directory
Replicator service. Damn it's friggin ugly and limited. Oh well, set up
a user account to do replicator service. Looks like you can only export
and import from a single directory tree. Yack.... Plus, I seem to
be having problems with replication failing due to "in use" errors (but
it doesn't tell me what is in use.) Arrggh, the policy file perhaps?
Something else that will ALWAYS be in use? Looks like it. Check out
Microsoft's
Tech database. Apparently all users must be logged out before replication
occurs OK... :-(
Also found out that system commander wants the first partition to be FAT. During an automated install on my workstation, the MBR got blown away and I had to FDISK /MBR it back (which blew away system commander -- no big deal since my PC was still not reconfigured from the crash last week.
On the brighter side, looks like my kludges with "thiscampus" host will work just fine. A simple login on a user account at Stanton worked as expected, with home directories mapped to the closest server.
Added following commands to maint.cmd to fix security hole in registry
After further checking, I found I need to define a user template
dir in system policies that point to the user's home directory. It would
be nice if it went into their roaming profiles templates directory, but
early tests didn't seem to produce that effect. Have to read up on
what policies take precedence, etc, etc...
Noticed I had not put "option adobe" into installs done at Wilmington. Damn. No Adobe Acrobat Reader was therefore installed. Will have to go back later. At least Stanton will be OK.
Did a sysdiff snapshot of Microstation. After I ran microstation, noticed that the damn launch icon pointed to E: and not G:. Gotta do that over again :-(
Getting final unattended install setups done for Microstation and AutoCAD. Hope to get them installed in the labs by the end of today.
Having some problems with "Slow Network Connection" dialogs on login. I am slowly bumping up the policy (in milliseconds) to try and find a reasonable value for this. In my mind, it'd have to be DAMN slow to remove the advantage of downloading one's local roving profiles. But then again, maybe not if IE really does stash its cache in the roving profile by default (we don't run IE -- yet. Someday Microsoft will force us I'm sure...)
Now the fun begins...
Leave it to Bob Foraker to find the first problem. Trying to launch autocad via a document icon craps it out. The start menu launch works OK. This is because the launcher creates an F:\ACAD directory, sets env vars, and launches autocad. Most of this could be easily parked into the login script -- at least the env vars. We could force the batch to run by changing the registry to launch it instead of the exe file.
On another note, the login script seems to fail (loop) when it can't connect to apache for shares. Need to correct that asap.
I may make up a kixtart routine to read values out of a file and set the default appropriately.
[S3.Mfg] %S3% Display Driver v2.00.18 = S3IncI changed it to:
[S3.Mfg] S3 Display Driver v2.00.18 = S3IncIf you don't do that, the unattended install will fail. (It just a comment entry basically anyway). The display section then looks like:
[Display] InfFile = "s3.inf" InfOption = "S3 Display Driver v2.00.18" InstallDriver = 1 ConfigureAtLogon = 0 BitsPerPel = 16 XResolution = 800 YResolution = 600 VRefresh = 75 AutoConfirm = 1All of this is documented in Microsoft support article. (God knows the URL will change. They like doing that. If so, search for "Install OEM Video Drivers with Windows NT 4.0 Unattended Setup".
Oh, also grabbed the drivers from S3 driver site, unpacked them, and copied the files to the $oem$\display directory.
During testing of the nursing software, I tripped across the NTVDM.EXE
process that goes to 100% CPU. Found the problem this time. See the notes
for Nursing Department software for
more details.
What did we ever do before the Internet support sites?
Anyway, doing that along with defining third party vid drivers (see
above for S3) worked like a champ. I just copied
all of the hal*.dll drivers from SP3 and removed the original corresponding
.dll and .dl_ files from the distribution.
I added this value to noautlog.reg. Not quite intuitive, but that key gets written during the auto install anyway, so I just added the item to it. Gets the job done! :)
Tried to figure out a way to fold the OEM driver into the install. Took ages and lots of reading knowledge base articles. Final solution was a bit of each item we read about.
We copied the entire OEM NT floppy directory structure to $oem$\c\drivers\3c90x directory, so it gets copied to each PC during install. Then we edited the oemsetup.info file and set the options up top to NO. Finally, changed the individual unattend.txt files for each station to look like below:
[Network] ; DetectAdapters = "" InstallAdapters = AdaptersList InstallProtocols = ProtocolsSection InstallServices = ServicesSection JoinDomain = thedomainname [AdaptersList] 3C905 = AdapterParameters, C:\drivers\3c90x\ [AdapterParameters]
After doing this, it works like a champ and runs unattended to boot (no pun intended!). Oh, did have a permissions problem after the install. Had to modify the acls.cmd file and make the below two files everyone:r
Since we have so few of these things left, it's hardly worth trying to fix this annoyance. Let's hope they all die a natural death.
Aye, no, that's it. It hangs trying to start explorer at that point. I found later that if I do a "control fonts" in the batch file, it does the job and all new fonts are indexed and available to users without any hassle.
start /w rundll32 Shell32.dll,Control_RunDLL Desk.cpl @0,3
AAARRGGGHHHH... DAMN DAMN DAMN DAMN... The *new* sysdiff will NOT apply any packages made by the old one. F%*$ing Microsoft strikes again... Looks like I'll have to rename the new sysdiff to sysdiff2.exe and make the ainstall.cmd batch file use the correct one. I am *NOT* remaking the old packages.... :-(
Hmm, one bit of good news I stumbled upon today. "setup -s" will install Nortan AV 5.0 unattended (and silently). Then run "live update" to update the installation with "NAVLU32.EXE /SCHEDULED"
With almost every software using Installshield as their installer: * Type Setup.exe -r . * Choose at will (usually Custom). * Let install finish. * Fetch Setup.iss from your windows dir. (If you need to, edit the file. It's just an ini file.) * Then on every other machine, do setup.exe -s . No dialog, no questions (unless something is missing from the setup.iss)
Unbelievable (if it works). Can't wait to try it.
More info from InstallShield's web site, article Q101901
Modified atiin4aa.inf and removed the section where it autoruns the little ATI systray icon (I hate that). Just look for any line that writes a registry entry to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and whack it out. change parameters in [Display] to:
[Display] InfFile = "atiin4aa.inf" InfOption = "ATI Technologies Inc. RAGE 128 GL AGP 2X (English)" InstallDriver = 1 ConfigureAtLogon = 0 BitsPerPel = 16 XResolution = 800 YResolution = 600 VRefresh = 75 AutoConfirm = 1Text in InfOption has to be EXACT!
for our purposes:
"ATI Technologies Inc. RAGE 128 GL AGP 2X (English)" "ATI Technologies Inc. 3D RAGE IIC (English)" "ATI Technologies Inc. 3D PRO TURBO (English)"are valid choices depending on gfx card
This supercedes/replaces the old ATI driver install, so all of the STATION files will have to be edited to reflect the changes.
NT will autodetect this NIC, but the drivers it installs do not work with this updated "B" model. Copied the Intel driver installation files to $oem$\c\drivers\e100b directory, so it gets copied to each PC during install; Essentially using the same method used to get the 3c509B card working.
Changed unattend.txt file to:
[Network] ; DetectAdapters = "" InstallAdapters = AdaptersList InstallProtocols = ProtocolsSection InstallServices = ServicesSection JoinDomain = thedomainname [AdaptersList] e100b = AdapterParameters, C:\drivers\e100b\\ [AdapterParameters]Works like a charm.
Used scripTIT to run the install from the driver CD through it's paces. Very simple and straightforward as far as sound installs go, that's why I chose this one first.
Copied the NT drivers from the Gateway CD to \$OEM$\c\drivers\sbpci64d and placed the scripTIT script in \$OEM$\c\drivers called sbpci64d.scr
OH!!! the current directory MUST be %systemdrive%\drivers\sbpci64d\english\drivers or the files will not install!!!
Here it is:
[SCRIPT]
run=C:\drivers\sbpci64d\english\drivers\sbsetup.exe
SBSetup={ENTER}
SBSetup=#{ENTER}
SBSetup=#n
Very simple.had to change ACLs on two files after this, the files comprising the SB Mixer app.
%systemroot%\system32\starter.exe and %systemroot%\system32\ensmix32.exegranting everyone read-access.
Added Crystal Audio soundcard support to automated install. This is the standard sound chipset that comes with Gateway E-1200 computers.
Used ScripTIT to manually configure audio driver through the multimedia control panel. ScripTIT sucks. It doesn't work as advertised so I had to find alternate means to navigate the dialog box, and was finally successful. (It doesn't seem to send CTRL-TAB key sequence correctly)
Copied the NT drivers from the Gateway CD to \$OEM$\c\drivers\crystalg and placed the ScripTIT script in \$OEM$\c\drivers called crystalg.scp
Here IT is:
[SCRIPT]
run=C:\winnt\system32\control.exe mmsys.cpl
Multimedia Properties={RIGHT 4}
Multimedia Properties=!a
Add=~
Install Driver=C:\DRIVERS\CRYSTALG~
Add Unlisted or Updated Driver=~
Driver Exists=!n
CrystalWare(TM) Audio Driver=~
System Setting Change=~
Multimedia Properties=# {TAB 5}
Multimedia Properties=~
Had to change ACLs on the special 3D mixer application for Crystal audio.
%systemroot%\system32\CWB3DSND.EXE for everyone:r
Added OMS application to local install. It simply makes a directory, copies all the files, opens permissions on the files and creates a shortcut.
Added a *TON* of new printer config sysdiff files and reorganized directory structure under */unattend/sysdiff. made a printer subdirectory and edited pinstall.cmd to reflect the new location.
printers that begin with loc_ are LOCAL printer configs, the rest are network printers.
Working on rolling out IEAK. We have little choice because it is REQUIRED for certain packages like Visual Basic 6 and AutoCAD 2000. Sigh... But, on the brighter side, the IEAK *does* look pretty good, especially if it worked as advertised.
For example, I made a package for the library patron stations that was very restrictive. I also built in a URL so it could grab a new .ins and .cab files on startup so as to change it as I went along. Only if this worked. I certainly can't get it to.
First, the run restrictions doesn't work too well at all. Looks like you can't put full path names in it, just the simple program name. Next, the changes you make just don't seem to work. For example, when rolling out my test kit, I set a restriction that you couldn't close the program. What I was hoping for was that it would prevent the final instance of the program from dying. In reality, it prevents ANY window from closing. So I changed that in the IEAK Profile Manager and saved it to the distribution URL. When IE starts on the test machine, it *does* grab the changes and does unpack the cabinet file and saves it in the machine's CUSTOM directory, but doesn't seem to do anything with them once there. :(
(Hours later...): Got it working. Damn flock()ing tech books from Microsoft fails to mention that the MIME type served from your web server better send out "application/x-internet/signup" for .ins and "application/octet-stream" for .cab files. I had to copy the damn things to an IIS server I have around and see what it typed them as. Jerks... :(
One useful other thing maybe to change iexplore.exe as the shell program. This is in "HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\Shell". I set it to "c:\program files\internet explorer\iexplore.exe" and it worked.
Nope. Making it the shell won't give the "browser customizations" a chance to kick it, yielding a plain vanilla install copy of IE. Which -- is interesting. That means most the customizations happen strictly in the registry (except for what's in the .ins file)
Connection Wizard program seems to be needed to process .ins files...
Moved "control fonts" from worker.cmd to post2.cmd because we now "pause" postboot.cmd to prevent explorer from loading and screwing up our RunOnce key we insert to get another Administrator login going. Doing this stopped the font window from opening to rebuild font index.
Arrggh, IE won't install unless at least SP3 is around. What, now we have to install a SP, then install products, then reinstall a SP? :-(
update:Nope. Doesn't work. Can't install an sp, ie,
then another sp all within the same boot without causing major
problems. Need to automate a reboot and login for each step. :(
1.5 days until the end of the world.
Anyway, these last few entries are a bit chaotic in nature. Hopefully I can
sit down and better organize the docs. A revamped install routine was
developed to handle the multiple reboot problems. Seems to work well. Had
some problems, like auto-logon failing in the second and subsequent logins.
Solution was to totally blow away the winlogon key and rebuild it with auto
logon info from scratch.
Outlook express seems to work fairly well, but the IEAK was
deficient in numerous areas on setup. Sure, it can set up default
servers and stuff, but why not have options to pull or make
assumptions about the user name. Hell, if the incoming server name is
foobar.xxx and the NT login name is baz, then why the hell not at
least have an option to assume the e-mail address is baz@foobar.zzz
automatically, and fill in the full name and display name based on current
NT account info. Oh well, looks like I'll have to do it for them. The
info is stashed in HKCU/Software/Microsoft/Internet Account Manager/Accounts.
Must read the key value "Default Mail Account" to get the key name to use.
After that, it's a piece of cake to fill in the required info. Also, for
some reason, IEAK doesn't have an option to turn on SSL for IMAP connections.
(Maybe it's because OE 5 *SUCKS* at it?!)
Arrggh, running IE for first time on an account that never has used it before
says that Internet Connection Wizard can't run. But but but... never mind.
Looks like that is flagged in the Internet Connetion Wizard/Completed key,
DWORD:0x1
Wait... even more problems. Almost no customizations were done. loadwc.exe
absolutely *must* be able to run upon login
More problems on library install. If domain admin logs in, all customizations
and restrictions are picked up fine. If other user does, none of them are.
Also, loadwc.exe is not stuck into run key, nor does sticking it in and
running it make a difference...
1430: On other stations, runonce is recycling. ie, stuff that gets
stuck into it for next reboot ends up getting run on CURRENT boot
cycle somehow.
1710: A KB article
(Q173039) says that if rundll32 is executed, entries in the
RunOnce key are executed. Arrgghh... Is it applicable to us?
Working on Office XP install. Same
package I made for Windows XP seems to work with NT so far, except it
requires a reboot in the middle of it to continue, which means mapping
the drive again... The damn thing also stops and says "it installed
ok" via a modal dialog box. :-( Perhaps installing windows installer
first will help... windows installer program doesn't install unattended. The web page
for it says to consult the SDK for command line parameters. I had to install
the damn thing just to read the docs, and all the command line params documented there are just for msiexec. After hunting all over using google searches,
I found a usenet post that says to use this:
Ah, but turns out it doesn't make any difference, it still needs to
do the systems file update and reboot. 30 April 2002
instmsiw.exe /q /c:"msiinst.exe /i instmsi.msi /q"
Official
URL for this page: http://www.stanton.dtcc.edu/stanton/cs/admin/nt/diary/
Page Maintained by: Ken
Weaverling