cluberti

If you just want to map the \Documents and Settings\User\Desktop folder to a different drive, just use the subst command - no need for it to be difficult .

No problem. I think this was in the documentation for the NT4 reskit - I remember I found it by reading it somewhere back around the '96 timeframe , and I think that's where I read it. edit: I did just try a google search, and you're right - not the easiest info to find unless you already know the reg keys .

You'd need a copy of the "new" shell32.dll, modified, to copy back after the hotfix has installed. You'd likely need SFC disabled to do this, however.

Yeah, RayOK is correct - those are OOBE questions, and wouldn't be asked by default unless you included the oobe inf (which you've done). I suggest a)scripting OOBE entirely, b)using another method (rather than OOBE) to script user creation, or c)use a tool such as nLite to remove as much of the OOBE as you are able.

I'm not sure why the reg entries aren't being added, but I know that if you run the script within Windows itself, it doesn't work properly - you get an "%%i not expected at this time" error, and that may be why the reg entries are not being added (just an educated guess, though, not 100% certain). Congratulations, you really made me think about this one! After a few hours of tinkering (yes, I'm terribly single-minded when it comes to "simple" problems like this ) I think I have something better to find a CD Drive letter, as well as making it persistent outside of this batch. This may be more useful in the long run, rather than checking in every batch, and you could conceivably use it in any batch file or script once this vbscript has been run. You'd have to run this AFTER Windows setup has complete, because WMI won't be available yet (at least not with reliable data) during Windows setup - it's something you could run in a RunOnceEx parameter, then reboot and do the rest via RunOnceEx again. If you use the AutoLogon feature of your WINNT.SIF file, you should be able to set the AutoLogonCount value to the number of required reboots for this to work (one for the vbscript, and one for each time you would've otherwise needed a reboot). Sorry it's not as easy to get up and running as a FOR IF SET query, but I never do things the easy way if I think they might not work every time . Anyway, here's the vbscript code you need to run first, before running your batch file: Const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _ strComputer & "\root\default:StdRegProv") strKeyPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" objReg.CreateKey HKEY_LOCAL_MACHINE,strKeyPath Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set colItems = objWMIService.ExecQuery _ ("Select * from Win32_CDROMDrive") For Each objItem in colItems strDrive = objItem.Drive Set colFiles = objWMIService.ExecQuery _ ("Select * From CIM_DataFile Where FileName = 'win51ip' " & _ "AND Extension = 'sp2' AND Drive = '" & strDrive & "'") If colFiles.Count > 0 Then For Each objFile in colFiles strEntryName = "CDDRIVE" strValue = objItem.Drive objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Next End If Next This script puts the CD drive letter in the registry as a value of "CDDRIVE", and it does so for whatever CD contains the win51ip.sp2 file (a file on the root of a Windows XP SP2 CD). After this has been run, you can just query this reg entry in your batch to set the variable, as so: %systemdrive% cd\temp reg query hklm\software\microsoft\windows\currentversion\setup /v cddrive > cddrive for /f "tokens=3 skip=3" %%1 in (cddrive) do set cddrive=%%1 You would now have a variable called %cddrive% - note that the variable will only be a drive letter and a colon, no backslash (D:, not D:\). Blasted "easy" scripts - nothing is ever as easy as it seems. I should've known better... Oh, and watch out for word wrap on the scripts - it seems the board software wraps some of the lines, at least at 1280x1024.

Actually, I believe that the only socket desktop 754 AMD chip to be 90nm is a Sempron chip, with the Palermo core (only 256KB L2 cache) - the desktop 754 socket Athlon processors are still the older Newcastle and Clawhammer cores, which are 130nm. I don't know of any desktop 754's other than the Sempron Palermo core chip being made on 90nm, and the only Athlon 64's in the 754 socket to be made on the 90nm core are the Athlon 64m processors, which are the mobile processors for laptop systems (these are still fairly hard to come by, in my experience). Note that the newer socket 939's with the Winchester core or newer (Winchester, Venice, San Diego, Manchester, Toledo) all are fabricated on 90nm. I'm pretty sure this is due to the fact that the 754 core has become the "budget" and mobile processor socket (which is what the Sempron is being fab'ed on), and the 939 and 940 are the "mainstream" and "workstation/server" sockets. If you don't have a 90nm chip, VMWare will not run a 64-bit guest OS. It's the only way (short of opening the box and looking at the die itself) to be sure you've got a rev.D Athlon 64.

If you're using Windows as your DHCP server: http://www.microsoft.com/technet/prodtechn...645ac58099.mspx

Are these people visually impaired, or completely blind? If they're blind folks, you need to take into account the space required by the hardware that will likely need to be used to read the screen, and the software related to that hardware. There are some different vendors making different products, so you may need to ask whomever is responsible for the hardware exactly what they plan on using, and whom you can contact (vendor-wise) about the software.

Not sure - since it's a beta, you should probably report it and see what the dev's say .

If you are installing from a disk or network, the $OEM$ folder needs to be inside the i386 folder, rather than side-by-side with it. That could be the reason files haven't copied over.

You should modify the new shell32.dll, with your icons and such, and replace the patched version with your own after the patch install is complete. Otherwise, you will lose your modifications to shell32.dll.

What folders do you have under $OEM$?

The unigraphics application - does it support running under 64bit Windows, or is it actually a 64bit application?

It's fine if you disagree - it's one of the things that makes the world go 'round . However, I do have some credentials that let me make the claim that more RAM makes almost any system faster, and at least have some credibility.

If you are on a domain and the users are not admins on their local machine, you can remove their permission to modify the clock's settings by removing their permission to change the system time. If you are not on a domain, you can still use the utility ntrights.exe (from the resource kit) to remove some group's ability to change the system time using the following command: ntrights.exe -r SeSystemtimePrivilege -u <user or group name> Note that you should not remove this privilege for administrative users, or you may have issues with the time synchronization service (w32time). That's why users need to be at least power users or lower to be able to do this. The resource kit is located: http://www.microsoft.com/downloads/details...&DisplayLang=en It will only install on 2K3 or XP, but you can then take the ntrights.exe file and run it on a Windows 2000 machine without issue, for what it's worth; it's a stand-alone executable.

gpedit affects everyone - but the nice thing about almost all of the policies there, is that they're just registry keys and settings. If you know what you'd like to set per user, figure out which registry keys are being used (if you open the .adm files, you'll see most of the info you're looking for), and set them in a particular user's registry. Note that only policies under the User Configuration portion can be set per user - some policies exist in both User and Computer Configuration containers, and as such can be set either in HKLM or HKCU, but policies that exist only in the Computer Configuration container can be set only in HKLM, and the same applies for policies in the User Configuration container and HKCU.

The files you wish to copy - are those in the $OEM$ folder, or the $1 folder?

Well, I don't condone or support piracy, but other than the two programs listed I have no proof that you don't own these apps (I can guess, since you do have two... questionable... applications, but I digress). As to the MSI installations, what happens if you run "msi /regserver" before attempting the installation? The service doesn't run unless it has something to do (meaning, start an install of an .msi package), regardless of whether it's automatic or manual in the Services control panel.

The "problem" (if it can even be called that) with updating the NT kernel is that the kernel isn't necessarily a stand-alone entity, as the Linux kernel is. If you have mismatched your kernel with the other files on your system, you will run into problems with stability and usability, especially with .dll functionality. If you wanted to use NT4 with a Windows 2000 kernel, you would need to replace almost all of the NT4 files with W2K files - and at that point, you'd basically be running Windows 2000 anyway . Updating the NT kernel files is possible, but it requires an almost wholesale update of all other critical core files on the system, thus giving you a system that is basically running the updated version of Windows already (and even this isn't going to be the most stable OS you've ever used).

Certainly. Again, only use ADS if you don't need the other functionality of RIS (like client deployments). If you are ONLY doing Windows Server deployments, you may want to go with ADS - with the caveat that it still has a relatively steep learning curve to get everything working the way you would like. If you already know RIS, you may be wiser sticking with what you know.

You can't do it in the winnt.sif file, but you can add registry entries via [setupParams] or cmdlines.txt to add the following values to your system's registry: Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Value: AltDefaultDomainName Type: REG_SZ Data: YOURDOMAINNETBIOSNAMEHERE Value: AltDefaultUserName Type: REG_SZ Data: yourusernamehere Value: CachePrimaryDomain Type: REG_SZ Data: YOURDOMAINNETBIOSNAMEHERE Value: DefaultDomainName Type: REG_SZ Data: YOURDOMAINNETBIOSNAMEHERE Value: DefaultUserName Type: REG_SZ Data: yourusernamehere

Oh, but think of all the time saved by writing in .NET . How many years has it been since developers had to worry about your disk space?

I voted "other" - I believe that common sense and being careful online are the best spyware blockers. For everyone else, Webroot's SpySweeper is incredibly effective at keeping a clean machine that way - for already infected machines, however, a combination of MS AntiSpyware, Spybot S&D, HijackThis, Process Explorer, Autoruns, and AdAware have always done the trick (and SpySweeper goes on the box RIGHT after it's clean).

Use "Process Explorer" from Sysinternals (http://www.sysinternals.com) to see the "Sample" process - you should be able to gather some information about the process, and where exactly it's running from on your disk, from Process Explorer. You may also wish to try "autoruns" (again, Sysinternals) to see if you can find what is actually starting the "Sample" process, and stop it from running until you can clean it out.