Mordac85

You might want to turn off the automatic reboots on system crashes. Right-click My Computer->Properties->Advanced tab->Startup and Recovery section->Settings. From there, uncheck Automatically restart under the System failure section. This way the next time you apply patches and it crashes, you should at least have a BSOD to read. Otherwise, you could boot from a WinPE CD and review the minidump files or patch logs.

It could just about be anything. Drivers, update applications, USB/wireless peripherials, screensavers, etc have all been known to cause issues with power management. I'd recommend updating all of your drivers and then step through the running processes/services/apps/desktop settings to see if they have any impact on the issue.

Winlogon is a Key and UserInit is a value under that key. No worries though. You might want to fire up msconfig to eliminate all of your startup items, then add them back in 1 at a time. It's slow and time consuming, but you get an idea of what's causing your startup issues. More than likely the explorer window is being caused by an app or service that had an issue during startup.

All you're doing is echoing the choices. You have nothing there to capture any user input. like @echo off setlocal <insert echo statements for the menu> Choice /C 12 /M "Enter option: " if "%ERRORLEVEL%"=="1" goto :Office if "%ERRORLEVEL%"=="2" goto :Viewer goto :END :Office C:\path to install batch file goto END :Viewer C:\path to install batch file goto :END :END endlocal or @echo off setlocal <insert echo statements for the menu> set /P IMG=Enter option (1 or 2): if "%IMG%"=="1" goto :Office if "%IMG%"=="2" goto :Viewer goto :END :Office C:\path to install batch file goto END :Viewer C:\path to install batch file goto :END :END endlocal Of course, you can probably come up w/a way to automate the install based on the user. If you really get ambitious, you can try using MDT

MS11-049 covers InfoPath and SQL server as well as VS. Depending on what you have installed, you can try the individual updates and possible QFEs to patch your system. You may also want to manually run the patch and use the /log switch to capture the error details. I'd also check the file version (microsoft.xmleditor.dll) to see if it is at, or past, the version that the update is trying to install (3.5.30729.5665)

fwiw, Windows is not as compartmentalized as other OS's and the components are intertwined within the OS. Some applications, even legacy folders, take far more effort to remove 'completely' than it's worth. As long as the service is disabled there should be no issue with it co-existing peacefully on the system. The result does not justify the time and effort spent. If you want total control over your OS, Windows is not for you. Now for the truly serious cases of OCD that just have to have it removed, the above obviously does not apply.

I assume this is a dual boot system and you're using XP more often. You might also want to check the disk for errors. Did the issue just start or has it been getting progressively worse? Was there any physical damage or shock to the system that may have either caused HW damage?

Interesting to know if new documents are defaulted to the 1st or 2nd folder, but it should be no issue. If the default is the 2nd subfolder then it sounds as if My Docs may have been redirected to My Docs, either manually or by policy. If it defualts to the original folder then all they did is dump everything under a subfolder and the name should have no bearing on operation. Just don't expect apps to find the My Music, My Pictures, etc that have been moved to a new location.

fwiw, the updater didn't solve my problem completely on either a slipstreamed SP3 and SP2 media. I had to update the Windows Installer to 4.5 as well.

You might also want to check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit (REG_SZ=C:\WINDOWS\system32\userinit.exe,). A trojan could have tried replacing the shell and the restored entry may still be wrong or be calling a leftover.

I can't speak to the mix of versions used, but I normally see this kind of issue with an incorrect HAL (APIC when it should be Uni/Multi or vice versa). I assume there is no alternate drive to swap out the questionable one, but since it's a Dell do you have the restore CDs?

I've also run into odd slipstreaming issues where XP doesn't always know the source included the SP or cannot detect it on the install CD after the installation is finished but when you need to pull from the source like when you add Windows components.

If it doesn't really need user interaction, why not use psexec or a WMI call to run the batch on the remote system? From there it should be easy enough to script it so you're running only 1 script against all 200+ systems. If you need user interaction, just add it to the logon script and send out an e-mail telling the users what they need to do before you enable it to run?

Actually, if you wanted to go to all the trouble of configuring an existing user profile I would recommend using the GUI to copy the profile to C:\Documents and Settings\Default User. If it's just a few reg hacks then load the hive and make your changes.

I set the default resolution, but once mini-setup loads the display driver it normally defaults to the max resolution without any adjustment needed on my part. After re-reading the question, I'm not sure if there actually is a problem. If the display driver is loaded, the resolutions are supported. Defining a default resolution in the inf does not mean they aren't supported, just not selected as the default. However, just because the video card may support a specific resolution does not mean the attached monitor does as well. Have you had specific issues with resolutions or are you just questioning the process?

OK, AutoLogon="Yes" in the WINNT.SIF or SYSPREP.INF are only intended to complete any build processing. To enable autologon once the build is complete you need to set some reg keys under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. MSKB 315231 gives you the details, but essentially you need to set these values: AutoAdminLogon=1 DefaultUserName=<user account name> DefaultPassword=<account password> DefaultDomain=<domain or computername if in a workgroup> But remember, if for some reason the user logs out and logs in with another username the DefaultUserName will change dynamically as it's intended to do, not to mention the password is sitting in your registry in cleartext. TweakUI can obfuscate this, but for those that know how, it's not difficult to obtain the password. Hence the reason autologins are not recommended on any OS.

You need to load the Default User hive (C:\Documents and Settigns\Default User\NTUSER.DAT) under, say HKLM as DefUsr, and then apply then changes to HKLM\DefUsr, not HKU. Then unload the hive and you should be good to go.

Isn't a theme much easier, and more reliable, than hacking shell32.dll? As soon as some hotfix updates that file you're going to lose all of your changes.

There's more than one way to accomplish this. You could use something like Microsoft Deployment Toolkit (MDT, formerly BDD) and create a Lite-Touch or Zero Touch Install or you could just create a PXE boot image (like WinPE) and script diskpart to handle drive partitioning and imagex to drop a WIM image on your box. Either way, there's a lot of work in setting up either in your environment so it depends on which way you want to go. Read up on MDT and figure out which way would be best for you.

I'm finding that not supporting problems caused by those rogue installs is helping. First thing I ask is 'who installed xyz' and if they say they did I uninstall it and Ta Da! All better! They normally freak when the uninstall starts, but when I point out that they aren't authorized to install it and that they'll have to discuss it w/their manager to get it back they tend to shut up. Oh and we have permission to yank out all of the crap (Google Earth, toolbars, Skype, etc) if we even see it on their systems. I love the security officer!

We'll never get rid of all the admins because they are too used to having the rights and would cry uncontrollably until senior management caves in just to shut them up. Actually, VMware's virtual desktop looks very promising and you can control the permissions to the applications so that the user's only have user rights but can run the app with admin rights if needed.

At work I've been testing & using Win7 since the inital Alpha release and we plan to migrate from XP to Win7. The way I see it Microsoft has 2 types of upgrades, plumbing & polish. Vista was a plumbing change and since it really wasn't ready for prime time, Win7 comes out and is a polish upgrade of Vista the same way XP was for Windows 2000.

That's because they are stored in the sysprep.inf, not the registry. Wrong, the local admin hive will be loaded once the login process is completed and accessible as HKCU. However, the hive will be locked and you will not be able to load it a second time. By default, there is no RunOnce under HKCU. There is, however, one located under HKLM\Software\Microsoft\Windows\CurrentVersion.If you are making changes to the user's hive (HKCU) then I would recommend using a single script to: Enumerate the valid local users Load each user hive under HKLM Make the change to that user's hive Unmount the user's hive and move to the next one

What did you do immediately before this happened? I normally see something like this when I'm loading an incorrect HAL.

I doubt it since I believe that is part of the explorer shell coding. Not that it can't be done, but you'd probably have to either re-code or replace explorer so it depends on you definition of 'tweak'.