cluberti

I currently do not notice any speed increases per se, but being able to run server processes on my workstation does come in handy (and not having connection limits is pretty useful as well in my environment). Server 2003 vs XP is probably a more personal thing when it comes to choice for desktop OS - Server 2003 is quite a bit more handy in certain situations than XP, and you should get similar performance for day-to-day operations, especially in x64 variants of both where the kernel is identical.

The DLLs corresponding to all application libraries not native to the OS have been grouped into several shared "side-by-side" assemblies and are installed into the native assembly cache, also called the WinSxS folder, under the operating system root directory. Similarly, while building an application using Visual Studio 2005, by default the compiler and the linker generate a manifest file that describes runtime dependencies of this application on libraries. This directory is used to keep different versions of development libraries separate - think "dll hell" for applications requiring specific runtime libraries, and this as a way to reduce that (by providing the correct version of a library to a running app without overwriting another version needed by another app). That's the non-technical version, anyway. Don't nuke it if you aren't sure you don't need it .

No, because detached program runs at T-39 during the GUI mode portion of setup, and sysprep does not run that portion of setup when min-setup is called. Sysprep only runs the basic configuration and PNP detection components of setup (including SID regeneration, if requested), and as such there is no equivalent of T-39 during mini-setup. That's the main reason that DetachedProgram is not a valid sysprep.inf parameter.

First, time.nist.gov is not a great place to sync your time unless you are required to do so - it's slow when not busy, and when it is the time server is sometimes inaccessible due to the fact that it's one of the only well-known internet time servers out there. Consider using pool.ntp.org instead - it'll use a local time server, and theoretically they are load-balanced and you will use a relatively responsive and underused one every time you check. I've found time on all of the AD domains I've been a part of has been much better and more reliable since switching from random time servers to the pool: http://www.pool.ntp.org Also, I've rarely run into the problems you appear to be seeing after making the previously mentioned registry changes and restarting the time service (although sometimes rebooting can clear it up on a finnicky server). Make absolutely certain that the machine you're on is indeed the PDCE!

Have you forced the TX rate and duplexing of the NICs on those ports? Auto negotiation can be problematic, even on higher-end hardware.

I'm not entirely sure (this is not party line), but I believe it probably has to do with making XP installable and image-able via WDS more than anything else.

NOTE - this assumes you have a PS/2 keyboard (USB will not work), and you can boot into Safe Mode: 1. Boot into safe mode w/networking (hopefully this will work) and fire up regedit.exe 2. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 3. Right-Click on the "My Computer" icon on the desktop and select "Properties"; this will open the "System Properties" window. Go to the "Advanced" tab and click "Performance Options". Click "Change" under "Virtual Memory". Set the pagefile to be located on the partition where the OS is installed, and set it to be equal to Physical RAM + 50 MB. 4. Also in the "System Properties" window, click on the "Advanced" tab, then click "Startup and Recovery". Make sure "Complete Memory Dump" is selected (see 4a if this is not in the list). You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed. 4a. If the "Complete Memory Dump" option in step 4 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 5. You will need to reboot the computer for these changes to take effect. 6. The next time that the computer hangs, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the computer to bugcheck and create the memory.dmp file. Boot back into safe mode w/networking to get the %windir%\memory.dmp file off of the machine for review. This will give us a complete memory dump of the machine in it's "hung" state, and we should be able to figure this out. I can give you FTP instructions offline once you've gotten the memory.dmp file. NOTE also that if you do press the keyboard combination in step 6 and the machine does not bugcheck, it's likely a hardware issue.

TheFlash is correct - most of those are files critical to Windows operation (more or less). System Volume Information - Contains volume data for the hard disk, including ntfs log flush files and cache data hiberfil.sys - The file used to write data in RAM to the disk for storage when the machine is put into "hibernation". ntldr - The Winodws NT kernel bootstrap loader. Delete this, and Windows will not load. pagefile.sys - The paging file, or "virtual memory". boot.ini - System boot information. You may get Windows to load without this file, but you should expect that it will not NTDETECT.com - Another file involved in booting the Windows NT kernel - see above statement about ntldr Recycler - The recycle bin Which ones? You can't easily kill processes critical to Windows' operation (and if you do find a way, you'll likely bluescreen/bugcheck your box, as you seem to be describing)

If winlogon is continually crashing, does the error occur in safe mode? It sounds as if something 3rd party has loaded in the winlogon process, and is causing it to crash - a winlogon crash will bugcheck or reboot the box (depending on the crash source and whether the error handler can handle the error internally or not). If you can get into safe mode w/networking, you should be able to run msconfig to disable all non-Microsoft startup and service items, but you should also be able to download autoruns (from sysinternals) and shellexview (from nirsoft.net) to further disable all non-Microsoft items - startup items, services, *winlogon providers*, explorer shell hooks, etc. This may get you back into Windows without the hassle of data backup or restore installation options.

Certain drivers are allowed to run in "ring 0" (where the kernel is running) in Winodws XP - including video and audio drivers. This can cause system sluggishnes or hangs if the driver misbehaves. That's the basic, non-technical explaination .

Instead of using GUIRunOnce in RIS, I've found that using the SetupParams section to call one .cmd file (that executes all of your other commands) works much better and is more reliable in the long run. It can also be used to pass parameters from your OSChooser screens into your actual OS installation, which is very difficult to do otherwise. For example, if I modified my OSChooser screens to allow the end user to determine which version of Office to install, which software build to install based on department, and whether or not to install certain other software, I could set those OSChooser screen variables up and then pass them to my .cmd file to act on those parameters, like so: [setupParams] UserExecute="%systemdrive%\temp\unattend.cmd %OFFICE% %SOFTWARE% %OTHER%" Obviously it takes some OSChooser screen knowledge/voodoo skills to configure if you want to pass things from OSChooser into the OS install itself, but it's MUCH easier in the long run to do everything this way (even if you aren't passing parameters). Note that the SetupParams .cmd file executes at T-12.

That is always possible. It's situations like these that led me to ultimately use WinPE to script and install all of my OSes from RIS, as it's much easier to have a "base" WinPE image that does partition creation, hardware checking, etc., then kicks off the proper OS installation afterwards.

There's no such thing as an "SP2" product key, as all Windows XP keys were built from the same algorithm. This means that any key that works in SP0 (RTM) will also work on an SP1 or an SP2 disc. However, if your key isn't legitimate, it's likely to fail on an SP2 machine due to the checking and "blacklisting" built into the SP2 install (and further now with the WGA checks). Otherwise, a legit, non-pirated (or non-keygen'ed key) will work on ANY revision of Winodws XP, slipstreamed or otherwise.

If you're getting errors printing as a non-admin user, the best thing to do to get an idea of where to troubleshoot is to run filemon and regmon (from sysinternals) while trying to print, and then reviewing those logs to see where the "Access Denied" errors occur. Note that some non-inbox vendor drivers just do not work in a shsared environment setting due to print processors or language monitors required by the print driver itself, thus meaning access to certain registry keys or file permissions will be necessary for normal users that would otherwise be restricted in a server environment - and even after fixing those issues, some print drivers will STILL not work as shared printers .

Have you tried also adding the "AutoPartition = 1" setting under the [Data] section of the .sif file? That, coupled with the "Repartition = YES" setting should wipe the entire boot volume and format one large NTFS partition.

I love the easy fixes

Have you tried pressing the "F5" key when prompted to press "F6", and selecting the "Standard PC" type?

Is this a multimon system - i.e., have you configured multiple monitors on the system? It sounds almost as if it's displaying the Window on a monitor that you cannot see (you can check in the Advanced tab of the Display properties).

You may be able to upgrade by installing the speech components of Office 2003, but more than likely you will need to upgrade the IBM software or run it on Server 2003 or Speech Server 2004 if you wish to use the current version of the IBM software.

The other question would be, does this happen with other browsers (such as Firefox, Opera, etc)?

IE7's protected mode relies on Vista's UAC feature, therefore disabling UAC will disable IE's ability to run in protected mode (regardless of setting): http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx

The SAPI (Speech API) v5.1 shipped with Office 2003, Windows XP, and Windows Server 2003, but Windows XP uses version 5 of the speech recognition engine (what you're likely having trouble with), whereas Server 2003 and Office 2003 use version 6 of the speech recognition engine. If you've got an application that requires SAPI v4.x (running version 4 of the speech recognition engine) or SAPI v5.0 or 5.1 (running version 5 of the speech recognition engine), I would suggest running it either on a Windows 2000 machine (as SAPI v4 shipped with Windows 2000) or a Server 2003 machine (optionally running Speech Server 2004), as SAPI v5.2 products handle v4 or v5.x speech applications probably better than SAPI v5.1 will, in non-scientific testing. Note that SAPI 5.2 ships with Speech Server 2004, and SAPI 5.3 ships with Windows Vista and likely Longhorn Server (and SAPI 5.2 and 5.3 products are leaps and bounds ahead of even SAPI 5.1 products using speech engine version 6).

Perhaps you've enabled (or it was enabled out of the box) a feature that keeps devices on the WAP from being able to communicate with each other?

The minimum requirements for a USB memory device to be readyboost capable is 2.5MB/sec for 4K random access reads and 1.5MB/sec for 512K random writes. Also, at least that data rate has to be achieved across the whole of the device's memory space, not just particular sections of the memory device. When you plug a USB memory device into the system, Vista does a performance check to see if the device meets the specs above, and Vista won't allow you to use a device it ascertains will slow the system down. Note that USB hard drives do not work as readyboost devices. Microsoft's general recommendation for maximum benefit from readyboost is to match the capacity of the memory device to the size of your system's physical RAM amount. That means that if you have 2GB of physical RAM, you should be using a 2GB USB memory device. Readyboost currently supports devices from 256MB to 4GB in size. In the future (after Vista releases to the general public or thereabouts), we should start seeing USB devices that actually display a "ReadyBoost Capable" logo. Note that I currently use a Patriot Xporter XT 4GB device on my 4GB Vista machine, and a Sandisk Cruzer Titanium 2GB device on my 2GB (used to be 1GB) Vista machine. Both are running post-RC2 builds, and both definitely handle day-to-day tasks better with the readyboost device plugged in. I don't have an "official" list handly, but there's some data at the link below that may steer you into the right device if you're looking for a readyboost device: http://www.grantgibson.co.uk/misc/readyboost/

If you add it to the "Top Level Domain Policy" group policy, it'll affect ALL machines on the network. However, if would be wiser to create a group policy object with only these remote assistance settings, and apply it to a new OU that contains all of the computer objects that this policy will apply to.