cluberti

Since USMT is a set of .exe's reading .inf files, automation is pretty straight-forward in a batch or vbscript. I'd suggest starting with the following article, and perhaps visiting the Microsoft Desktop Deployment Center for further assistance: http://www.serverwatch.com/tutorials/print...10825_3482606_2 http://www.microsoft.com/technet/desktopde...nt/default.mspx

Something running INSIDE explorer.exe is 99.999% the reason for the crash, not explorer.exe itself (it's just a shell application, and anything can host itself inside if it is coded to do so). Download autoruns from sysinternals and shellexview from Nirsoft and disable all non-Microsoft shell extensions, services, and startup items using these two tools. Reboot, and the problem should go away. At that point, you can start selectively re-enabling things until the problem returns - you should uninstall the offending program tied to whatever ends up being the root cause of your explorer.exe crashes. Good luck.

A quick test would be to create a new print queue on Computer A, but don't use the epson driver (Note that they aren't network aware, most of the time, so it may very well be the driver). Try installing the print queue using one of the built-in drivers, such as an HP Laserjet or Generic Text driver. Once that's set up and shared on Computer A, go to Computer B and try to print to that printer - assuming your network or firewall on Computer A isn't at fault, it should work properly.

I think I'll use some of that one and modify my own...

vbscript to the rescue: 'Enables the Notification Area icon for IP enabled Network Connections, regardless of name. 'Modifies CurrentControlSet001 as observed when modifying via GUI. 'Creates requisite registry entries if missing. 'Reboot required for script completion. Dim objReg Dim objWMIService Dim colNetCards Dim objNetCard Dim strNICguid Const HKLM = &H80000002 strComputer = "." 'Period = local computer strKeyName = "SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\" strKeyName001 = "SYSTEM\CurrentControlSet001\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\" dwValue = 1 On Error Resume Next Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colNetCards = objWMIService.ExecQuery ("Select * From Win32_NetworkAdapterConfiguration Where IPEnabled = True") For Each objNetCard in colNetCards strNICguid = objNetCard.SettingID objReg.SetDWORDValue HKLM, strKeyName & strNICguid & "\Connection", "ShowIcon", dwValue objReg.SetDWORDValue HKLM, strKeyName001 & strNICguid & "\Connection", "ShowIcon", dwValue Next Set objReg = Nothing Set objWMIService = Nothing Note that you have to run this from within Windows itself, in a startup script or runonceex - running it during setup has a chance of failing (I've seen it work and I've seen it fail from T-12).

Install userdump from the microsoft site, create a rule to dump on all errors in explorer.exe, and the next time it happens you should have some .dmp files to review. Since this is likely a shell extension issue, you may want to run shellexview and disable all non-Microsoft explorer shell extensions, as well as running msconfig to disable all non-Microsoft services and all startup items and reboot. Once you've done that, see if the issue still occurs - if it does not, start re-enabling services and startup items, testing each time to see if the problem occurs. If you've re-enabled startup items and services and the issue is still not happening, you can start re-enabling shell extensions to see which one causes the crash. Or, you can just use userdump to dump explorer.exe on crash and debug to find out exactly what is happening, without all of the trial and error .

If it works the second time, it's actually likely NOT a DNS issue. It's likely IE either had, at one point, a dial-up connection configured, is configured to autodial in the registry, or has proxy information that is invalid. I would check to make sure that HKCU and HKLM \Software\Microsoft\Windows\CurrentVersion\Internet Settings\EnableAutodial is not =1.

Have you added the /usepmtimer switch to the boot.ini file?

Is it all new users that are not appearing, or just some new users (and others appear to be created properly)? The Exchange RUS is responsible for creating new Exchange mailboxes and populating the proper AD data for the user for Exchange - you may want to turn up the logging to see if you're failing anywhere, as this is likely an Exchange issue.

That's correct - you need to use $oem$\textmode if you are using =yes

You might want to check the registry for HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and make sure that the EnableAutodial registry value is set to 0.

OK, sounds like IE is misbehaving, but we don't know why. An easy way to debug this is as follows: Before anything else, install the "Debugging Tools for Windows" from: http://www.microsoft.com/whdc/devtools/deb...installx86.mspx Once these tools are installed, do the following: 1. Create a directory called c:\adplus 2. Click on IE to open it - as you have stated, you should get an iexplore.exe process in task manager, but no visible window 3. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 4. Type the following command in the command prompt: cscript adplus.vbs -hang -pn iexplore.exe -o c:\adplus 5. You'll get some warnings about symbols - ignore them (click OK) 6. When adplus finishes running against the iexplore.exe process, you'll have a "hang mode..." folder in C:\adplus, that will contain (amongst other things) a .dmp file. You can either open it yourself in windbg or cdb and debug, or you can zip it up and PM me and I'll give you some FTP instructions on where to upload it, and I can debug for you.

No - unless you install the full TS services, only 2 connections. When 2003 is installed without the TS server component, you get the old Windows 2000 "Administrative Mode" TS - 2 concurrent connections. When you do install the full TS server, you get as many connections as you are licensed and/or the server can handle.

That one is INACCESSIBLE_BOOT_DEVICE, meaning XP doesn't have drivers for your IDE or SATA (or SCSI) controller - did you provide it an F6 driver?

And what's the bugcheck code? Is it a 0x7e?

A Stop 0x7e or 0x17e mean that a thread executing in the system context crashed or access violated, and the error handler was unable to handle the exception and thus causing the bugcheck. These things can be a real PITA to troubleshoot, but if you would like me to take a look at the dump PM me and I'll give you FTP instructions.

Are the COM+ and DTC services running, stopped, or starting/stopping? I've seen this after installing MS06-018 (913580) and rebooting.

The number of DC's you will need is not going to be something that we can determine until we know more about your environment - as in, how many different sites/subnets and OUs, DC hardware (cpu/disk/memory), how many Exchange 2000/2003 servers (if any), network speeds, roaming vs. local profiles, how many Terminal Servers, how many print queues in the AD, how many computer and user objects, and whether or not you are going to be using things like DFS. Assuming decent hardware (dual processor/SCSI RAID/4GB RAM servers), for 1,000 users in an environment using Exchange, a few Terminal Servers, roaming profiles, lots of print queues, DFS, multiple sites, and a few thousand computer objects, I'd say at least 1 DC for each site. If you are going to have everything configured in one site, I'd say at least 2 DCs in that site (preferrably 3 or more).

If you are unable to boot into safe mode command prompt mode, you will have to do an in-place upgrade of your Windows OS (repair install does not repair the WPA issue). Otherwise, if you can boot up normally and connect to the registry remotely from another machine whilst the machine is up and running, you can do the registry edits in KB310794 remotely and reboot. Again, if you can't get into safe mode command prompt mode or do a remote registry connection, you will be resigned to doing an in-place upgrade (reinstall).

Download shellexview from Nirsoft (free) and disable all non-Microsoft shell extensions and reboot. Explorer is likely trying to load a shell extension handler at the point of the crash, and obviously it isn't going well . Disabling the shell extension should keep the handler from trying to load, and if disabling the non-MS shell extensions resolves the issue, you can then do a divide and conquer on re-enabling those to see which one is the offending extension.

Create an OU and a GPO, and assign the new GPO to the new OU. Then, block policy inheritance on the new OU, and then only the new (blank) GPO will be applied to machines/users in the OU.

Well, there's no Microsoft tool that I'm aware of, but you can create the following registry key on your DFS machines: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfsr\Parameters\Enable Audit Enable Object Access Auditing for these servers (via local or domain-based group policy) for SUCCESS. You will then see security audit events in the upstream and downstream partner every time something is replicated (7002, 7004, 7006 events). You could also write an app to use the WMI APIs for the method version vector (basically you'd take before/after snapshots). These steps are all I'm aware of, currently.

You could also get a network trace from the machine and reproduce the issue to make sure it's an access denied (0x80004005 is the hex for it) - ethereal or netmon should show you if that is truly the case (and my guess would be yes).

If you go to the %windir%\system32\spoo\printers folder, you should see your printer "shares" - what are the permissions for that user on the folder, and what happens if you add that user with "full" control?

No one is really ever on the boards in force on the weekend, and couple that with this being a holiday weekend in the US, the traffic here has been quite low. Too bad no one answered your questions, and glad to hear you have resolved your issue, but just keep in mind next time that posting late Friday, Saturday, or Sunday will generally require waiting until the next Monday (or, in case of a hoiday, even later) to get a good reply.