On Fri, 3 Oct 1997, John Blair wrote:> 1) How do you format the C: drive from Linux so Win95 can use it? > Have you already exited Linux and I'm missing something? > 2) What tricky problems did you run into with IO.SYS?I found that the best way to prepare C: before installing the pre-made Win95 tree onto it, was to use the command-line utilities supplied with Win95. That part of the process looks something as follows: 1. Run Linux fdisk with commands piped to it, causing it to remove any currently existing partitions on the hard drive, then creating one partition which takes up all the space, has it's partition ID set to 6 (DOS 16-bit >= 32M) and is has the DOS active flag enabled. The script code that does this is: echo -e 'd\n 1\n d\n 2\n d\n 3\n d\n 4\n' \ 'n\n p\n 1\n 1\n' \ $(hdparm -gq /dev/hda \ | tr -s ' ' \ | cut -d ' ' -f 4 \ | cut -d / -f 1)'\n' \ 't\n 1\n 6\n a\n 1\n w\n' \ | fdisk > /dev/tty3 2> /dev/tty3 (Note that all the workstations I need to support with this have one IDE hard drive, but the size varies. The above copies with this nicely.) 2. Second, I boot dosemu (Linux DOS enviroment), with its boot floppy image set to a file mounted from the server, which is a DOS 7.0 boot disk image containing: <standard DOS boot files> FDISK.EXE FORMAT.COM AUTOEXEC.BAT (contents below) EXITEMU.COM (exits dosemu) AUTOEXEC.BAT contains: fdisk /mbr (sets the hard drive master boot record) format c: /s /u /autotest (something like that at least) exitemu (exits the emulator, so the process continues inside Linux) This effectively means that when I execute dosemu, it prepares C:, then exits immediately - no user interaction involved. The format happens quite quickly, since dosemu "absorbs" the BIOS int 0x13h (I presume) calls issued to format disk tracks, so only the filesystem creation etc really occurs, which is perfect for what we're doing. This puts IO.SYS etc on C: where we want them - later when the archive is extracted onto the hdd, IO.SYS is overwritten, but since it's the same file, it gets overwritten in place and stays valid. If not, I'd simply remove IO.SYS from the install tree, of course.> I'm know I'm asking for all sorts of details, but you've hit on > something potentially really useful. I'm excited to try it out.Please ask away - I'll be leaving the office shortly, but I'll be back to follow up on Monday morning. Regards ---------------------------------------------------------------|-----|-- Louis Mandelstam Tel +27 83 227-0712 Symphony /|\ /|\ Linux systems integration http://sr.co.za Research { } { } Johannesburg, South Africa mailto:louis@sr.co.za (Pty)Ltd {___} {___}
Louis Mandelstam <lma@sacc.org.za> writes:> On Fri, 3 Oct 1997, Luke Kenneth Casson Leighton wrote: > > > > 1. A completely automated Win95+apps installation from the server, from a > > > boot diskette (for setting up new PCs or fixing completely hosed ones) > > > > how??? how??? > > I know how you feel ;-) > > First I tried using Microsoft's msbatch.inf plan for automating setups, > with batch.exe and the like. > > After spending probably about 2 months concentrating on this, scouring the > web, DejaNews, Samba archives, peers and the Win95 Resource Toolkit, I > came to the following conclusions: >[ ... ] Interesting. More or less exactly the same solution we arrived at. We now have a similar setup where it is possible to install Windows 95 with the "push of a button" by first booting into Linux and copying existing installation trees from a server. We initially mucked about with a diskless configuration, but this is so bug ridden, that I would recommend against anybody trying it. At least one other department is doing the same thing at our site, btw. Maybe there is really a lack of communication here and a mailing list would be a good idea. One tool that I found very useful for keeping workstations in sync after installation or to upgrade them with new files if required is PCRdist, which works in a similar fashion to BSD rdist, except that the file synchronisation is initiated from the client (Win 95). It is (inexpensive) shareware available from http://www.pyzzo.com/.> > > 8. Automatic printer selection, per-workstation. I expect I'll have to > > > set up a table on the server with printer name to use for each > > > workstation, and come up with a way to update the registry accordinly > > > at boot time. To make it fun, not all the printers are the same - but > > > almost all understand PCL5. I might be able to get rid of the rest if > > > I have to. > > > > how? > > Dunno, still need to ponder this one. I may end up trying to make a > single printer service on the Samba server, connect all workstations to > that service (so they all have the same setting) and let the server figure > out which printer should get the job. Otherwise I may figure out a way > to feed an appropriate .reg file to the workstation from the server (at > boot time). If I could find a way to let Linux exit back to DOS after > booting using loadlin.exe, I'd have a very simple way to do a lot > of boot-time things - since I could just get back into DOS and let the > Win95 boot continue from there (after modifying the registry in any way I > please).[ ... ] It is possible to extract all the entries that the installation of a printer leaves in the registry and various .ini files and apply that information (via regedit and a little tool that I wrote for changing .ini files) to a machine that does not have the printer installed. No user intervention is required. This makes it possible to "install" certain printers automatically on certain workstations, but not on others. Another approach would be to do a printer install via Samba browsing, which has the disadvantage that a little user intervention is required. It works like this: Make all the printers available on the Samba server and make sure they all have correct "printer driver = .." entries (these tell Windows what printer driver to install automatically if that printer is accessed). Have the Windows 95 installation tree from the installation CD somewhere available on the Samba server (just the stuff that resides in the WIN95 directory on the CD is necessary). It should be accessible via a share, let's say WIN95CD. Make sure that Windows 95 believes it was installed from that share by adding the entry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup] "SourcePath"="\\[YOURSAMBASERVERNAME]\WIN95CD" to the registry. As soon as a user doubleclicks on the name of a printer in the browsing window (assuming the printer has not been installed yet) a prompt window is shown with the question, if that printer should be installed on the system. After pressing "OK" the rest of the install is done without any more user intervention and the printer is available on that workstation from then onwards. One more drawback of that method is obviously that only printers with drivers on the Windows 95 CD can be installed in this fashion. Or is there a way to add additional drivers to the various .cab files? This would also be interesting for drivers for other peripherals. In a previous mail you wrote:> 3. User profiles are in their home directories, allowing roaming. Still > have some work to do here, such as disabling the "You have not logged > into this computer before...." message, and forcing a "Yes" instead,There is a way to do this. It is a hack not worth seeing the light of the high quality discussion going on here, but mail me anyway for details if you are interested.> > 4. The desktop is the user's home directory itself. It works here because > these users only use Win95, so there aren't any non-PC/Win95 files in > their homedirs.Did you actually get all the relevant entries in the registry to point at the users home directory as the desktop? Or does this work in the "ususal" way that the desktop is copied from/to the server at login/logout? If the former, I would be very interested how you did it. Regards, -- Joerg Lenneis email: lenneis@wu-wien.ac.at
On 5 Oct 1997, Joerg Lenneis wrote:> Make all the printers available on the Samba server and make sure they > all have correct "printer driver = .." entries (these tell Windows > what printer driver to install automatically if that printer is accessed).I've been thinking of trying to make this work using a PRINTER$ share - i.e. manually - I didn't even know Samba had an option for this. I don't run any NT here, but I can report that if you share a printer with drivers not from the Win95 CD, other Win95 machines connecting to that printer share will pick up the driver from it, so it is possible. They seem to be getting the driver using the PRINTER$ share which points to the windows\system directory, which is where the printer drivers live. (There are some security-related consequences which I wrote about in a post to the Samba list several months ago). Perhaps by putting all the printer drivers into a directory on the Samba server, and sharing that directory as PRINTER$, will allow clients to get the driver for printers not included on the Win95 CD. Allmost all the printers I need to support fall into this category - HP LaserJet 5Ns. Presumably the Win95 client tries the PRINTER$ share on the printer's server first, then it's Win95 install dir second. (Or perhaps its own SYSTEM directory between those two)> As soon as a user doubleclicks on the name of a printer in the > browsing window (assuming the printer has not been installed yet) a > prompt window is shown with the question, if that printer should be > installed on the system. After pressing "OK" the rest of the install > is done without any more user intervention and the printer is available > on that workstation from then onwards.If I could automate this step, I'd be very pleased. Another correspondent has posted details on the method I suggested regarding letting all the clients connect to the same printer share, and letting the server sort out what to do with the jobs (haven't read the post properly yet - but I'm assuming this is the case) For me, this seems to be the best way forward - it lets me do things at a very convenient granularity.> > 3. User profiles are in their home directories, allowing roaming. Still > > have some work to do here, such as disabling the "You have not logged > > into this computer before...." message, and forcing a "Yes" instead, > > > There is a way to do this. It is a hack not worth seeing the light of > the high quality discussion going on here, but mail me anyway for > details if you are interested.Right now I'm interested in anything I can get - please ;-) What I really need is to change the behaviour from comparing the registry on the hard drive with the profile on the server, and using the newest one (and creating one on the hard drive if none existed there) to always using the profile, and paying no attention to a hard drive copy, or even whether one exists or not.> > 4. The desktop is the user's home directory itself. It works here because > > these users only use Win95, so there aren't any non-PC/Win95 files in > > their homedirs. > > Did you actually get all the relevant entries in the registry to point > at the users home directory as the desktop? Or does this work in the > "ususal" way that the desktop is copied from/to the server at > login/logout? If the former, I would be very interested how you did > it.Perhaps there are some problems I still have to run into, but I've done some extensive testing with this and the applications we have here over the last few months, and it seems to be working fine, and I didn't have a hard time doing it at all. I'm using system policies, and the default template provided with poledit.exe has a user policy which lets you set the location of the desktop, programs menu, start menu etc. That's all I used. What problems are you experiencing? Up to Friday, I'd been setting all system registry settings, as well as user default settings by setting them in my install tree archive. This is proving to problematic because: a) is very time consuming - I'm tuning registry entries, and every time I want to try something I need to test it, then update the registry on my "mastering" PC, create a new archive, and test it on another machine. Takes about 15 minutes and I loose state info from my thoughts while waiting. b) Making changes later on, when the distributions is running on end-users' machines, will require a re-install - which I already have automated, but it's overkill for just changing registry entries. I played a bit with setting an appropriate .REG file which is loaded after login by feeding it to regedit during the login script. Would have solved my problem nicely, but I've found to my dismay that it doesn't work reliably. Under some circumstances, I get an error box claiming the .reg file I'm trying to import could not be found (no problem with path or permissions etc and since it's in the netlogon share which is where the logon script itself sits, this doesn't make sense). Also, the login process sometimes hangs (mprexe is reported not to be responding, and I have to hard reboot) Now, from some very frustrating and time-consuming experimentation, it would appear is if the above problems only occur if the user logging into the machine is doing so for the first time, and/or doesn't already have a profile stored on the server. The problems don't occur reliably, but do more often than not - in 100% identical cirumstances (well, you know what I mean..) This is driving me insane, so insane in fact that I'm actually willing to consider using Microsoft's method of updating registry entries from the server at login time - system policies. I am in fact already using system policies to set things like control panel restrictions, however to control the whole registry as I need, I require a lot more than the default poledit.exe template offers, so on Friday night I found myself once again reading the Win95 Resource Kit in order to learn the tample format. Add one more file format to the collection :-( It certainly looks like I'll be able to do what I need using the system policies (i.e. setting an entire registry to be the way I need at login time) but it does not seem as if the system was designed to handle static registry entries, such as, say, Netscape's 'viewers' section. Besides, converting the .REG master I have now into a .POL I can't do directly since .POL is a binary format, and I can only seem to write it using poledit.exe, which I can only customize using .ADM template files. It would seem that my best chance would be to write a Unix script to convert a .REG file into a .ADM file, using "DEFAULT" keywords to set values, then using poledit.exe to convert it into a .POL file to save onto the server as CONFIG.POL I would really appreciate hints or comments on this, since no matter which way I turn, it would seem that I have several work hours to wade through before even knowing if that approach will work as hoped. Regards ---------------------------------------------------------------|-----|-- Louis Mandelstam Tel +27 83 227-0712 Symphony /|\ /|\ Linux systems integration http://sr.co.za Research { } { } Johannesburg, South Africa mailto:louis@sr.co.za (Pty)Ltd {___} {___}