cluberti

Thanks . I didn't want to rewrite something that was already written so clearly. It was my hopes that people would click the link

Slow down - I won't go into my credentials, but I've use this method for years, and it works. It does create a valid, working setup disk, and the Windows setup routine is not case sensitive. Also, the routine I mentioned uses mkisofs to create the CD file structure, which does create a CD structure that XP setup can read without problems no matter what DOS or another .iso reading tool may say. For example, look at the structure of the mkisofs CD image from within WinRAR, then look at the same .iso from within ISOBuster. Note that you'll see two different things - XP's setup routine sees the filesytem on the CD as WinRAR does (which appears fine), not literally, as ISOBuster shows. As long as your original source tree is setup correctly before running mkisofs against it, it WILL work fine setting up Windows.

Yes, it's still pretty important to install patches chronologically, because you're patching a source that has no way of knowing if you're integrating an older file from an older hotfix on top of a newer file already in the source - the source you're integrating to isn't running, so the whole smart patching thing goes out the window. Negating the need for qchain on a running system is nice, but when you're /integrate'ing a flat file source, how is it going to know if you're doing it right??? And some files get updated EVERY patch (and I can think of a few that if you break, Windows won't boot right), so it's even more important to be careful!

What exactly is broken? We run huge FTP servers at MS on Windows 2003 without issues (other than FTP being an incredibly insecure protocol, but I digress)...

Nothing's foolproof - firewalls can cause a machine to not be in the browse list, network problems, flaky WINS servers, router lag, etc. If you really want a WINS and NetBIOS primer, search the MS site - there's a wealth of info there on how NetBIOS and WINS work. Microsoft started moving away from the browse list and WINS in general with AD and building everything on DNS, but it's still good info for supporting older technology.

You should have received the updated .adm file with the wsus download. On the server in question, it was placed in %windir%\inf - copy the wsus .inf file from that server to one of your DC's, open the GPO you want to add the settings to, and under Computer Configuration right-click on Administrative Templates, and choose add/remove templates. Click the Add button, and you should see the .inf you copied over. Select the INF, and the settings will now be under Administrative Templates in your GPO (somewhere in the network subtree, I believe).

We use these tools a lot for exactly this type of thing

Go into the control panel, then system properties > Advanced tab > Performance Settings button > Advanced Tab > Change button. Is the "Paging File Size" listed after C:?

It can't do much compared to 2000 or 2003, either .

Are there drivers for the device under Windows 2000? I have a few Creative Webcams that work in 98 and NT4, but not 2000 or higher.

Is your pagefile.sys on C:?

For an .exe, you could look at the source, decompile it (not likely), or debug it while it's running (assuming you understand machine code and call stacks). If you want a high-level overview, download filemon and regmon (from www.sysinternals.com) and run both, then run your .exe, then stop both regmon and filemon. They'll give you a snapshot of what just happened on your system, both on the filesystem and in the registry. It's best to run those when NOTHING else is running, short of Windows itself, because they're VERY verbose. Less is more, in this instance, if you want to see what is actually happening.

Actually, you are correct. It is indeed the OS kernel that is responsible for memory management (unless the app was written in C++ and uses it's own memory management handlers, bypassing the NT memory manager, but I digress - I don't want to bore you ). And you are correct, in general Windows XP doesn't release memory that an application has freed immediately. It waits for a time before it releases those memory addresses back into the available pool of virtual address space. Depending on what is running, what your commit charge is, the amount of physical RAM, your Paged and NonPaged kernel pool sizes and usage patterns, what kind of memory swings your system is seeing due to application memory usage, how many handles applications are using, how many threads the system is running, your page fault (hard and soft) deltas, the size of your page file (getting the idea yet? ), and also kernel vs usermode CPU usage patterns all determine how long Windows XP "holds" memory before freeing it back into the free memory pool. Windows becomes more and more aggressive at releasing that "held" memory when the system starts to run low on virtual address space that can be mapped to actual physical memory - it will start releasing held memory quicker when the amount of address space mapped to physical RAM grows close to the full amount, and it will also start swapping out address space located in physical RAM to the pagefile to make sure that critical and running applications take preference in physical RAM over those that have been idle or are running in the background (in that order). Again, the best book for understanding (and optimizing) the Windows kernel is "Windows Internals" (4th Edition). Get the hardcover if you can - I've worn out the binding on one already, and am on my second .

If you're in a domain, you can have a "default" profile of sorts - create the folder structure \\<dcserver>\netlogon\Default User\. If that folder structure exists in your domain, new users will use that profile when they log on to a new machine and create a new profile. You could also use roaming profiles with this, in which case your problem would be solved that way as well.

[Data] Autopartition = 0 [unattended] Repartition = No Windows should then prompt you to partition during the installation.

Google is your friend: http://msdn.microsoft.com/library/default....stemrestore.asp

Not entirely sure - Try putting the files in $oem$\c\temp and calling %systemdrive%\temp\<filename>.cmd. SetupParams are called at the T-9 stage, not T-13.

The file may not be able to be defragmented, but it's location on the disk would still be optimized by the defragmenter in the course of it's cleanup.

Usually a machine rebooting at this stage would signify a hardware issue - have you tried removing everything but your video card and a known-good stick of RAM from a working machine?

Since we're posing registry tweaks B) : http://www.cluberti.com/regtweaks As to making your regtweaks import, do as I've told everyone else with this issue - don't use cmdlines.txt for reg entries or RunOnceEx - in your WINNT.SIF, use: [setupParams] UserExecute=%systemdrive%\temp\unattend.cmd Place your reg files and your runonce.cmd file in $oem$\c\temp\, and make a file called unattend.cmd (in the same folder), and add: --- unattend.cmd --- @echo off %systemdrive%\temp\runonce.cmd regedit /s %systemdrive%\temp\<name of your registry entries>.reg ----------------------- Then, your registry entries are called and added at the T-9 stage. This works much better than cmdlines.txt.

Cool

Not a problem.

ccApp.exe is a symantec file, shared by multiple applications. MPR.dll is a Windows system file (Multiple Provider Router) that has existed since Windows 95. However, in Windows NT (and 2000, XP, 2003, etc), a particular function in this .dll was removed for (massive) security reasons - WNetEnumCachedPasswords. If you're running Windows NT, 2000, XP, or 2003, this error (while problematic) is expected - the function no longer exists, and any application trying to call this function will fail. If you're running Win98 or WinME, replace the MPR.dll file on your system with one from the Windows CD. If you're running an NT-based OS (and I'd guess you are running XP ), get an updated version of ccApp.exe from Symantec, because that's where the problem lies - it's not an XP problem, it's a Symantec problem.

To install MSMQ post-install (which is what I'm guessing you are after): 1. Create an answer file with the following components: Msmq= To perform an unattended installation of Message Queuing software, make sure msmq=ON. To perform an unattended uninstallation of Message Queuing software, make sure msmq=OFF. Unattended uninstall automatically removes all message and log files. Type= This entry specifies the type of Message Queuing component to install. There are three valid settings: IND, RS and DEP. Specifying IND for a computer running Windows 2000 Server or Windows 2000 Advanced Server installs a Message Queuing server without routing services Specifying IND for a computer running Windows 2000 Professional installs an independent client Independent client is the default installation type if the entry is not specified. Specifying RS for a computer running Windows 2000 Server or Windows 2000 Advanced Server installs a Message Queuing server with routing enabled. You cannot specify RS for a computer running Windows 2000 Professional. Specifying DEP installs a dependent client You cannot install a dependent client on a Windows 2000 domain controller. ControllerServer= This entry specifies the NetBIOS or DNS name of the Message Queuing server running on a Windows 2000 domain controller that will be used to communicate with the Message Queuing installation type (IND or RS) being installed in the specified site. You may not have to specify this entry. Setup will try to automatically find such a server. If it fails however, unattended Setup will not continue. If an entry is specified, then unattended Setup will use the entry and will not attempt to find the server automatically. Do not use this entry if you are installing Message Queuing on a Windows 2000 domain controller. SupportingServer= This entry specifies the NetBIOS or DNS name of a Message Queuing server that will be used to support the dependent client being installed. This entry is required. ServerAuthenticationOnly= Use this entry only for clients that will communicate with MSMQ 1.0 controller servers running Windows NT 4.0 and that will need to authenticate such a server. SupportLocalAccountsOrNT4= This entry is used to support computers running MSMQ 1.0 on Windows NT 4.0 and computers that are logged on using a Local User account. If this entry is set to true, such computers are able to query Active Directory and view Message Queuing objects. If set to false, such computers are not able to query Active Directory. If used, you must set this entry to true on the first Message Queuing server installed on a Windows 2000 domain controller in your forest. This setting weakens Active Directory security. For the security implications of setting this entry, see Weakened security considerations Site= Use this entry if you are installing a Message Queuing server with routing services enabled (RS installation type). Message Queuing Setup may not be able to automatically resolve the proper site if subnets in your network are not configured correctly. You specify the default site containing the Message Queuing server running on a Windows 2000 domain controller that this server will communicate with. DisableAD= This entry is used if you are installing Message Queuing in a workgroup environment or any environment that does not have Active Directory. If set to true, the ControllerServer entry is ignored and the computer will not attempt to connect to a domain controller to access Active Directory. Such a computer requires direct connectivity to other computers to send and receive messages. This entry is applicable only if you are installing an independent client or a Message Queuing server without routing on a nondomain controller (Type=IND). 2. Run the following command to install MSMQ based on your answer file: sysocmgr.exe /i:%windir%\inf\sysoc.inf /u:<path and file name of answer file>

Try something like DeepFreeze to safeguard the PC, or just having Ghost or RIS reimage or reinstall the PC every night. As for the data, get a USB hard disk and copy it there, removing it from the PC's hard disk entirely. That way, you can lock away the USB hard disk or copy that data to another PC somewhere else that you feel safer having the data on.