Mordac85

Right, forgot my timeline there. When this does fail is the domain name listed in the "logon to" field or is it the computername? I'm wondering if the cmdlines.txt command is not being set or the value is being reset afterwards for some reason, but you need to find out what that registry value is when it fails.

Sorry, I forgot to get back to you. Seems that the DefaultDomainName key is being set to the computername during setup. I forget if that's the default action, but I think so. You may want to use something like GuiRunOnce to run a req add and set the value of DefaultDomainName to your domain.

The DHCP depends on what you're comfortable with, and whether you can absorb the admin overhead to configure a static IP for each wireless user (most secure) if you don't use dynamic assignments. But if you're using a Radius server, I'll assume you already have some kind of DHCP server so I'd just stick with that and make a new scope for wireless there. As for DHCP servers, I prefer dhcpd on linux since it's easier to configure and I can manage it all from scripts. At work I have to deal with Windows, but at least they have the MMC snap-in to make it just as easy to manage, just thru a GUI. If you have the wireless node that can act as a router as well as an AP, then if you use your existing DHCP server just use it as an AP. You cut down on the points of failure and make troubleshooting much easier, but you have more work on the configuration end to get it up and running (like changing the router to handle the new subnet). As for the flag, I didn't see an option for Scotland. But maybe if you PM a mod, they can tell you if it's possible to add it.

Sounds like a decent basic plan, but here are a few other common sense items you may want to add if you haven't already: Get an actual site survey to determine the optimum AP placement and make sure they provide you a good diagram of signal strength for those points. Disable SSID broadcast Use a unique SSID and not something that's easily identifiable as related to your company Use anything but channel 6, since it's the default it's quite noisy Use anything but WEP. WPA2-AES or WPA-TKIP is much better. If you need to use WEP, plan on changing the key every few days Use MAC address filtering if the administrative overhead is acceptable Restrict DHCP scope to match the number of users as closely as possible

I'll assume the print server \\MPX is in a workgroup and that the printer is shared from there since it seems to be causing all this trouble. You need to connect/authenticate to \\MPX with an account on \\MPX not an account on one of your local systems. So if you had an account, say MPX\2Print (it doesn't have to be an adminstrator account), then just add an entry to HKLM\Software\Microsoft\Windows\CurrentVersion\Run with your net use command to \\MPX\ipc$, or just the printer \\MPX\HPLaserJ (e.g. net use \\MPX\ipc$ /user:MPX\2Print <password>). That should run at every boot and establish a connection to the print server. If MPX is actually a server I'd recommend setting up a domain, tasks like this are so much easier with a common group of accounts and if you're tackling unattended installs it's not that far of a stretch and would make some of those tasks easier also.

I guess it would depend on how setup reads the file, so you'd probably have to test that. Or you could switch to something like a powershell perl or vbscript script to run your processing. Then you could use a hash or dictionary object to read in the section contents like this powershell example. get-content sysprep.inf | foreach-object {$infData = @{}} {$infData[$_.split('=')[0]] = $_.split('=')[1]} and then access the key using $infData.key1

Gotcha, sorry I didn't read carefully enough. I thought you just wanted to autologon. So the logon prompt is coming up and if you cancel that and hit CAD again it steps thru just fine. When you have the logon prompt up, exactly what values are listed for each field?

We use Servswitch at work in the server racks, but at home I use Trendnet. I have the PS2 and the USB 4 port versions and have had no problems. Just make sure you realize that if video quality is important you'll have to pay for it. For my lab and normal home use the cheaper KVM's are just fine. Also, an external power supply is handy so you're not dependant on pulling power from the computers.

I understand all of the theory, but I've never found a utility/script that is able to actually get a remote system to turn on. Has anyone ever actually got this woking and, if so, how?

I use a WinPE boot image for the PXE boot in my test lab. From there I run Ghost to drop the image on the client. But I only do this in my lab b/c of the time to copy the image off the network. Business Desktop Deployment (BDD) is the M$ solution, replacing RIS for the most part. It seems more complicated to setup but looks like a good tool once it's up and running.

I bet the problem is that XP has no support for AHCI by default, and the pirated copy probably had it added in. Try checking in the BIOS to see if you can switch to ATA mode or use F6 to provide the sata drivers when you start. I just had a similar issue with the Dell Optiplex 755 ICH9 controller.

If the only location you have for drivers is %WinDir%\inf, you do not have to specify it in OemPnPDriversPath since that is the default. If you do have custom drivers defined check to make sure you didn't alter the path structure defined in the driver inf. I normally delete all the helper app crap and platform version I don't need then just have the drivers in the root with the inf. But I have to review the inf/oem files to make sure it didn't reference the files in their previous subdirectory.

Your problem is this value. The rest of the first section is spot on, but just drop AutoLogonCount and you should be OK. Just make sure you're not using autologon after mini-setup b/c it'll get disabled when setup decrements the counter specified in unattend/sysprep, just like it does with this registry value.

What are you using to get the user input and add the entry to sysprep? Can't it handle RW to an ini file? Worst case would be to build the setup and test it.

Are you connecting directly to the printer or a print server queue?

Some more details would be helpful on the issue and what you're getting vs what you expected. Knowing which SID you may be referring to, user or computer account, would help

From what I can tell you may be stepping on your own toes trying to enable all instances of autologon. Once mini-setup completes it will autolog you on for x number of times. Once that threshold is reached, it resets HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon to 0 (disabled). If you want autologon all the time, don't mess with the autologon after mini-setup at all. Configure the Winlogon keys in the registry and let it do it's thing. Also, since you are setting up autologon, skip trying to do so with a blank password. It will be in the Winlogon key for reference if you forget, so just set one. nbd

I'm actually really liking Kubuntu more and more for a desktop replacement since it can be so very hands-off like Windows. Adept updates run like Windows Automatic Updates, just about everything works out of the box and I can actually be productive on it quickly w/o having to wrestle with a variety of config files. Plus, it's Debian based so it's very stable (at least for what I'm doing). It also has sudo setup by default so I don't have to worry myself over the root account. You can fiddle with it to your heart's content, but if you just need to get it up and running in a usable state this is it. I actually stumbled on it b/c I was finding a lot of solutions in their forums.

I've never seen a driver behave this way, but you may be trying to use an older, or incorrect driver. I'd recommend checking the INF to see if the signature="$Windows NT$", plus the date and version of the driver. If it has "$Windows 95$", then obviously it's not an XP driver. Otherwise, check the Details tab of the device in Device Mnager check the PCI ID string to make sure it's listed in the INF properly. You should find the first portion of the ID string in there somewhere. For instance, if your NIC has an ID string of PCI\VEN_14E4&DEV_1600&SUBSYS_01C81028&REV_02\4&378EDFA4&0&00E2, you should find PCI\VEN_14E4&DEV_1600 or PCI\VEN_14E4&DEV_1600&SUBSYS_01C81028 in the INF. The INF may also have a section specifically for XP, called out in the Manufacturer section, and will usually look something like this: [Manufacturer] %BRCM% = Broadcom, NTx86.5.1, NTamd64Where the NTx86.5.1 is specifically for XP and there will be a section called, in this case, Broadcom.NTx86.5.1 and your ID string needs to be listed there for the driver to instlal properly.

The BTS driverpacks are already broken down to the simplest dir structure w/small names to make sure you can fit them all into the 4096 character limit. Consolidating multiple drivers into a single folder as you propose is, theoretically, possible only if there are no duplicate filenames; however, managing that would be a nightmare if you ever had to come back to it and figure out what driver is where.

In an INF those are comma delimited values, so I would assume your string value is evaluated as a single parameter instead of 4.

That's the correct line for PST. What is the clock set to in the BIOS?

I have an XP image that, on some models, will have the dialog to choose where to search for drivers (default locations or a specific location) pop-up during the hardware detection phase of mini-setup. You don't have to do anything and it eventually finds the required drivers and all is well, but to reduce the confusion, and for my own knowledge, is there some setting that is causing this dialog to pop-up? I have all my driver paths defined in the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath and not OemPnPDriversPath in the sysprep.inf.

And rsb seems to expect a different answer to the same question. Was there something in the other thread you didn't understand?

Were you able to manually install the drivers afterwards? This would eliminate the hardware as a source of the problem and leave the install routine.