cluberti

Get everything the way you'd like it to be on new installs for your profile, then copy your profile's ntuser.dat file to your CD. I use the following to copy that to new installations during setup in a script in [setupParams] (obviously with some other things in the folder structure as well, but the ntuser.dat is the most important file): attrib -h "C:\Documents and Settings\Default User" attrib -h -r "C:\Documents and Settings\Default User\Application Data" attrib -h "C:\Documents and Settings\Default User\ntuser.dat" xcopy "%sourcepath%unattend\profile\Quick Launch" "C:\Documents and Settings\Default User\Application Data\Microsoft\Internet Explorer\Quick Launch" /s/i/q copy /y "%sourcepath%unattend\profile\Internet Explorer.lnk" "C:\Documents and Settings\All Users\Start Menu" copy /y "%sourcepath%unattend\profile\Windows Explorer.lnk" "C:\Documents and Settings\All Users\Start Menu" copy /y %sourcepath%unattend\profile\ntuser.dat "C:\Documents and Settings\Default User" copy /y "%sourcepath%unattend\profile\Task Manager.lnk" "C:\Documents and Settings\Default User\Start Menu\Programs\Startup" copy /y "C:\Documents and Settings\All Users\Start Menu\Windows Update.lnk" "C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools" attrib +h "C:\Documents and Settings\Default User" attrib +h +r "C:\Documents and Settings\Default User\Application Data" attrib +h "C:\Documents and Settings\Default User\ntuser.dat"

If you've got your XP CD, boot to the CD and use the recovery console option. This will give you a console where you can replace the file, both in system32 and dllcache without Windows actually running. Either that, or put the HDD in another machine and replace it there.

Not even on the microsoft.com website yet...

DHCP and DNS registration traffic in themselves are very light, almost unnoticeable in a network trace. I'd worry more about Windows Updates and Antivirus Update traffic before I even thought about DNS registrations and DHCP DORA processes, bandwidth-wise.

The DNS TTL is separate from the DHCP lease lifetime. Go to the properties of your DNS zone and you should see the TTL information displayed on the SOA tab. I would strongly suggest using a shorter lifetime in DHCP for your Active Directory clients, due to issues such as these - especially if you have laptop users. I don't suggest leases longer than 24 hours in an AD environment, and 12 hours or less is even more preferrable.

Good to hear you found a solution. I'd say it's funny that the policies weren't applying, but remember that almost all policy objects are just registry keys, so you can always do (or undo) it manually .

A twist on the others, that I find easier to read: 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:" _ & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colChassis = objWMIService.ExecQuery _ ("Select * from Win32_SystemEnclosure") For Each objChassis in colChassis For Each strChassisType in objChassis.ChassisTypes Select Case strChassisType Case 1 strEntryName = "MACHINETYPE" strValue = "Other" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 2 strEntryName = "MACHINETYPE" strValue = "Unknown" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 3 strEntryName = "MACHINETYPE" strValue = "Desktop" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 4 strEntryName = "MACHINETYPE" strValue = "Low_Profile_Desktop" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 5 strEntryName = "MACHINETYPE" strValue = "Pizza_Box" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 6 strEntryName = "MACHINETYPE" strValue = "Mini_Tower" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 7 strEntryName = "MACHINETYPE" strValue = "Tower" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 8 strEntryName = "MACHINETYPE" strValue = "Portable" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 9 strEntryName = "MACHINETYPE" strValue = "Laptop" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 10 strEntryName = "MACHINETYPE" strValue = "Notebook" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 11 strEntryName = "MACHINETYPE" strValue = "Handheld" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 12 strEntryName = "MACHINETYPE" strValue = "Docking_Station" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 13 strEntryName = "MACHINETYPE" strValue = "All-in-One" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 14 strEntryName = "MACHINETYPE" strValue = "Sub-Notebook" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 15 strEntryName = "MACHINETYPE" strValue = "Space_Saving" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 16 strEntryName = "MACHINETYPE" strValue = "Lunch_Box" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 17 strEntryName = "MACHINETYPE" strValue = "Main_System_Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 18 strEntryName = "MACHINETYPE" strValue = "Expansion_Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 19 strEntryName = "MACHINETYPE" strValue = "Sub-Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 20 strEntryName = "MACHINETYPE" strValue = "Bus_Expansion_Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 21 strEntryName = "MACHINETYPE" strValue = "Peripheral_Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 22 strEntryName = "MACHINETYPE" strValue = "Storage_Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 23 strEntryName = "MACHINETYPE" strValue = "Rack_Mount_Chassis" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case 24 strEntryName = "MACHINETYPE" strValue = "Sealed-Case_PC" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue Case Else strEntryName = "MACHINETYPE" strValue = "Unknown" objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strEntryName,strValue End Select Next Next

What's the TTL on your DNS records? If the TTL hasn't expired, the client update will be ignored. The update would only occur when the client got a new IP address after the DNS entry's TTL had expired. Otherwise, there will be no update until manual deletion of the record or TTL expiry. Scavenging wouldn't work, because likely none of the records had expired yet, and thus were not "invalid" yet.

I agree with the previous poster - if it's a really old machine, consider installing Linux on this box (instead of Windows) and run a Linux-based DHCP server.

On this machine, I do not have that value at all. And the registry data looks clean, the version check and the imagefileoptions check all passed OK. You've got some issues with reparsing (which could be caused by disk I/O at the time), but nothing out of the ordinary. It's definitely a policy issue as far as I can tell from this.

1, 2, and 7 are probably more important in troubleshooting this service anyway. On a side note, I'm not entirely sure what I did with step 5 .

I'm not aware of any software that restricts software being installed, but software restriction policies work very well on Windows XP (if you're willing to invest the time in configuring it, which I highly recommend in any case). Note that software restrictions policies don't affect Windows 2000 machines, so other more draconian measures may need to be inflicted to the 2000 users For a little more info on Software Restriction Policies in XP via Group Policy, review the following: http://support.microsoft.com/?kbid=310791

Read that EULA you agreed to carefully - you have a license to use the software the way the OEM sees fit, and in the way they can allow you to with regards to the OEM's actual license with Microsoft to provide the software. In Europe this is less of a limitation due to the invalidity of certain portions of EULA's in regards to most European laws, but here in the US you'll have to (legally speaking) take it the way it's given. It depends on the vendor, and the agreement they have with Microsoft - you need to be a rather large OEM to provide actual operating system CD's with your OEM computers, and it does cost more for the OEM per machine to provide the whole CD as well. They can meet their support requirements (the vendor supports Windows when they ship it with their hardware, not Microsoft - it's in the EULA) by shipping a restore CD or restore partition, and since it's cheaper to do so and harder to get an agreement from Microsoft to actually provide the OS CD's, they do this. Also, be careful of installing a retail or VLK copy of Windows XP on an OEM machine - a lot of EULA's forbid this, unless you purchase the copy of Windows from the OEM itself (and all Windows upgrades, btw). The reason for this is that if you call MS for support on a retail OS on an OEM machine, they won't support it and will direct you to the OEM. Since it isn't the OEM's version of Windows, they won't support it and will direct you to Microsoft... Not that most of us would care, but just an FYI. Dell usually provides a full OS CD though, unlike other vendors *cough*HP*cough*.

As to the logout time issues, consider installing the uphclean utility from Microsoft to alleviate logout issues - most of these are caused by antivirus software or printer drivers keeping the user's registry open, and uphclean forces open registry handles to close when a user logs out. As to the profile issues, you will need to configure a user profile exactly the way you'd like, then copy that profile to the "C:\Documents and Settings\Default User\" folder, not the All Users folder. If you have a domain, you can simply create the folder structure \\<domain controller>\Netlogon\Default User\, and copy the user profile to that location. Any user that logs onto your domain, if creating a new profile, will first check this network location for a new profile before using the Default User profile on the local machine. If you've got Group Policy, you should be able to set the default wallpaper background and screensaver via Group Policy Objects - otherwise, this can be done the same as the previous via the Default User profile.

If you are asking whether or not you can set up a DHCP server on a Windows 2000 Professional machine, yes. However, it will not be from Microsoft - you will have to use a 3rd party DHCP server product, such as Vicomsoft DHCP server or Incognito IP Commander.

Run regmon (http://www.sysinternals.com) when attempting to install an .msi file to see which registry key is blocking your access to install .msi files - you could also enable MSI logging in Windows XP to get a detailed log of the installation as well.

Note that if the software doesn't need to write to HKLM or HKCR keys, even regular users can install them (because regular users do need write access to the HKCU portion of the registry). It's better to have software restrictions and run restrictions policies in group policy set - users can install the app, but they won't be able to run them when the .exe matches a restriction policy (and they'll get a message stating such as well).

XP SP2 fully patched - Internet Explorer crashed when running the code, but no calculator. Also, Trend A/V went nuts (which likely is what caused IE to crash). I know we like to knock Microsoft about security vulnerabilities, but Windows (and thus, IE) is a quite complex basket of code. I think it's a little disingenous when a security firm finds an exploit, and rather than let the vendor know beforehand post the exploit to the wild. Instead of contacting Microsoft and giving them time to fix the exploit, let's make everyone unsafe by releasing the exploit to all of the script kiddies of the world. Yes, IE is vulnerable - but are we less or more safe now that this "security firm" released the exploit code to the wild before letting the vendor know of the problem?

This could be any number of things - NTFS permissions have been locked down on the files in question, dll's may have become unregistered or corrupted, or the actual Logical Disk Manager service failed to start or is hung in a starting or stopping state. You can do the following for the above issues: 1. Check the NTFS permissions on the DCOM object itself 2. If you can find the AppID for the CLSID listed in the event viewer, you should be able to find what application it is and try re-registering the .exe's in DCOM. 3. Try stopping and starting the Logical Disk Manager and Logical Disk Manager Administration services 4. Disable startup items and services via msconfig or autoruns and see if the problem returns after a reboot 6. Uncheck the "Allow Service to Interact with Desktop" within the RPC service and reboot if it is checked. 7. Check the DCOM NTFS permissions specific to the application. If al else fails, read KB193888 on the Microsoft site to try and delay the service from starting: http://support.microsoft.com/?id=193888 Good luck.

If the logged on user is a domain admin, then you should have no problems. If the user isn't a domain admin, they'll need a few domain rights delegated to their user accounts or groups.

Good luck - I think you'll find the PS drivers to be much more stable though.

You'd be better served to join the domain after installation, probably best during RunOnceEx in a script. You could use the vbscript to write a registry value, then use that registry value to change the computer name and join the domain. Note that this would be a two-boot process, because you'd need to reboot after changing the machine name before joining the domain.

I think you've answered your own question - at least partially. You can still access those files (they are there on the disk), but you'll need a third-party tool that can read from the disk apart from the file system. Most system recovery CD's floating around on the 'net can do things such as this, and there are commercial products out there that can do this sort of thing as well (my favorite is NTFSDOS professional (from the Winternals' Adminpak, http://www.winternals.com/Products/AdministratorsPak/).

Almost all of the Windows Installer policies are under Computer Configuration > Administrative Templates > Windows Components > Windows Installer. Note that any policy setting that has been configured from "Not Configured" to a value cannot be reset by changing it back to "Not Configured"; it must be set to something else.

You'd have better luck using Linux's GRUB to overwrite or repair the boot sector after Windows 2003 is installed. There's no way to keep Win2K3 from overwriting the MBR (and it will never detect your Linux install properly, no matter what distro or boot loader), but using your Linux boot floppy you should be able to get back in and "fix" it via GRUB (it can be done with LILO too, but most newer distro's use GRUB at this point).