cluberti

Well, you should know first that it only supports installation of Windows Server operating systems, 2000 and 2003. Second, you will not be able to run it on a server that already has RIS installed (and, to be honest, you'll have a hard time running it on any network subnet that is already configured for RIS). Other than the WMI interface, I don't find ADS to be a must-have, when RIS can do the same job (albeit with more manual configuration). Since RIS also supports client OSes, it makes more sense if you plan on using this to do more than server deployment. If you're only doing server deployment, ADS should be fine.

If your network card can PXE boot to the network, you can use RIS or one of the other open-source alternatives to RIS to create a Windows installation share that is accessible via only booting from the network card.

After a brief google search, it seems that there are quite a few people having problems with LG drives in general under x64, but there are quite a few others who are having no issues. With that said, perhaps it's just a firmware issue? http://gb.lgservice.com/

This should work, as long as you copy the data, rather than move it. Copying files results in the security permissions being applied to the copied files from the parent folder they are moved into (unless specifically disabled in the parent folder's properties), whereas moving files moves the file's previous permissions and attributes over (unless it is across actual volumes, in which case both do the same as copy). Sometimes you would actually want permissions and attributes to follow a file or folder, but not in this case.

If you can get the printer installed on another machine, you can use the printmig tool to move the printer and the ports over to any number of other machines. I know it isn't as pretty as a vbscript, but it does work .

You wouldn't happen to have a Symantec or Veritas product installed, would you?

A P2 350 is slow, but I think the original poster is aware of this. However, 198MB of RAM is a relatively low amount of memory to have in an NT-based system (even NT4 worked better with 256MB of RAM, 10 years ago). Adding more RAM makes the system run faster (note that I didn't say BOOT faster) - applications will still be CPU-bound when loading up for the first time, or executing large amounts of code whilst running. But only having 198MB of RAM means that (even on a non-nLited W2K box) you only have about 120MB of RAM after you've logged in to the system, on a clean box. 40 - 50MB of RAM is taken immediately on boot by kernel nonpaged pool (and this pool can and will grow to 128MB of RAM if needed, on a 198MB box), and another 20 - 48MB of RAM is taken by desktop heap allocations (again, can't nLite this away either, as it's a kernel function). Do the math, and 198MB of RAM on an NT-based system is just not enough to use comfortably, and will affect system performance. You can reduce the footprint of the rest of the OS with nLite, but you still only have around 100 - 120MB of RAM available when you are finally able to start using the box after boot. Adding more memory gives the system some breathing room, and reduces the need for the Memory Manager to keep paging memory pages in and out to keep RAM available for the kernel nonpaged pool (again, up to 128MB needs to be available at all times in physical RAM for this pool). Note that I did say "The 350MHz processor doesn't help" . I was being dry, even somewhat sarcastic. But I still stand by my statement that the RAM is the bottleneck in almost all systems with 256MB of RAM or less - the kernel and running services can consume up to 100MB of RAM on their own, before the user's applications even get launched. I suggest reading the Windows Internals (4th Edition) book if you really want to know how the Windows kernel works.

As a previous poster stated, you will need to create the following registry value: Key: HKLM\System\CurrentControlSet\Control\StorageDevicePolicies Value: WriteProtect Type: REG_DWORD Value: 1 This key will not exist, so you will have to create it yourself to enable the write protection to external storage devices.

You can access your admin shares via the loopback adapter, as long as you have the rights to view the drives and shares they point to. Since you most likely have at least read access to the C: drive (or you'd find it hard to boot Windows ), you will be able to access that administrative share (C$) via the loopback adapter. This is normal behavior. If you can access your administrative shares from a REMOTE machine via the machine's name or IP address (without entering proper authentication information), then that would be an issue.

This would log everything after winlogon hands off to explorer.exe, after a user has put in their username and password.

You CAN, but you SHOULDN'T. This will put you "out-of-compliance" with your Microsoft licenses, which can be a bad thing if the BSA comes knocking. Every computer should have a unique PID, created from a unique product key (it's in that EULA we all click through without reading). Using the same key on all of your machines will work technically, that is correct - but even if you have unique licenses for each PC you're installing, if you use the same key for all of them, you're violating the license from Microsoft for all but one of those PC's. Just an FYI.

Even though you didn't believe me, glad to see my answer was still correct - good for the ego, you know . J/K This switch will work for Windows Media Player, and most Windows Media Player hotfixes and updates (except perhaps Windows Media Connect, but that's techincally a shell update and not a WMP-specific update). Glad everything's working again.

That depends - since the Windows kernel requires up to 470MB of paging file space, I'd say stick with at least 500MB to keep the system from having to resize the paging file due to running low on virtual memory (this can cause paging file fragmentation, which is to be avoided if at all possible). Also, if you plan on using large files (or large amounts of little files) in daily use, having a large paging file will actuallly *increase* performance, because of the way in which Windows handles the file system cache - it is stored entirely in kernel paged pool memory, which itself is stored entirely in the paging file. Having enough space (again, up to 470MB) in your paging file will increase system performance if you plan on using your system in such a way. If you ever have a system crash and need to debug the memory dump, you'll need at least 2GB + 50MB to hold all of the data, but if you don't foresee the need for such an occurence, I'd say 500MB is best. Remember that Windows may still attempt "page out" virtual address pages mapped in physical memory to the paging file if those pages are not accessed after a good amount of time, as necessary. It may do this even if you have most of your physical memory available.

Make sure you're looking at a netmon trace for the error, for that's where it would be seen (not on the machine's GUI). Since most people are running Windows domains on their networks for their Windows machines to connect to, using the "Microsoft Windows Network" provider first will provide the fastest login times (due to the fact that the "Web Client" provider will not be able to be used to log onto a Windows domain). Also, if you're using the Web Client provider, you have to wait for the provider to time out (5 seconds is the default, IIRC), the redirector to be closed and reopened, and then the Microsoft Windows Network provider to be called and initiated. This can add 7 or 8 seconds to login or boot times. \This one deals with the "connection to resources" issue, and particularly in IE - although the port matters little. Most web services use the IIS server to provide authentication, which causes AD lookups if NTLM or Kerberos are the authentication methods used by IIS. Thus, a domain controller running a web service that requires authentication will also be doing NTLM and/or Kerberos authentication lookups for web client requests, on top of authentication for domain logins via a winlogon process. This means the DC is doing double-duty, logon-wise. This can (and often does) cause login slowdown issues if the web service is used heavily. If you use a UNC path in a system's environment variables, and there is a problem with the client accessing the UNC path during login, your boot process will be held up waiting for the UNC path lookup (and authentication handshake, if one needs to be done). This can take upwards of 5 - 7 seconds or more, depending on the network speed and congestion, the load on the server hosting the share, and even antivirus software on the client. This obviously will slow down the logon process by a few seconds or more at times.

I've got a good idea of what is going on here: Stop 0x000000C2 errors are ALWAYS caused by a driver - either it is attempting to free an allocation that has already been freed, or it is at a bad IRQL. Note that this can be caused by faulty hardware, but it is very unlikely to be the case in most situations. According to your callstack, it appears that the driver in question is trying to free an allocation that has already been deallocated (that's what the 0x00000007 parameter means). However, to determine the driver that is actually causing the pool header error, you would need to set the system up to do a complete memory dump, and run the resulting memory.dmp file through the debugger the next time the system bluescreens. The driver is NOT identified in a Stop: 0x000000C2 error, although the pointer to the location in kernel pool memory that caused the bluescreen is - the third of the four memory hex values is the pointer that you could use within the debugger to dump the drivers currently loaded, get the memory addresses of the drivers, then trackback from the pointer in the bluescreen until you come across one of the drivers. If you don't have experience debugging, I would be more than willing to do so if you can get me a full memory dump file the next time this happens. Again, unlike what most are saying here, I'd bet that this is a software issue (driver), rather than a hardware issue, as the error code states clearly that the BSOD was caused by a driver misbehaving in memory that is functioning correctly otherwise, rather than a corrupted memory address (if the callstack had a different first value, it could point to hardware problems, but a 0x7 address is 99.9% a driver problem).

Place the following in the [unattended] section of your winnt.sif file: ProgramFilesDir = "G:\Program Files" CommonProgramFilesDir = "G:\Program Files\Common Files" ProgramFilesDir(x86) = "G:\Program Files(x86)" CommonProgramFilesDir(x86) = "G:\Program Files(x86)\Common Files" Works great on my x64 CD's. I think yours fails to work due to the space you had between the "ProgramFilesDir" and "(x86)" portions of text - note that the above lines don't have any spaces in the vairables.

If it's an .msi, you can change .msi installers to always install with elevated rights (regardless of who's logged on) - but the change needs to be made in both the Computer and User trees of the GPO under the Windows Installer policy folder. Otherwise, you'll need to figure out which registry keys and file folders the users will need write access to and grant those permissions via GPO (yuck), or make them local admins on their boxes temporarily (also yuck).

Before I started using Adminstudio, inctrl5 always worked well at tracking system changes.

The value is actually in the CLSID key inside the LDAP key - however, if you do need to import it, the following will work: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\LDAP\Clsid] @="{228D9A81-C302-11cf-9AA4-00AA004A5691}"

Yes, you need to install 1.1 and 2.0 if you want both to work on your system - they're not interchangeable or backwards-compatible. In the future, you may want to do a quick search of the boards before posting, as this has been answered a few times already here - and you probably would've had your answer quicker. Just an FYI.

Your file is missing the header that tells Windows it's a registry file - it should look like so if you want it to work (all .reg files need the "registry header"): Windows Registry Editor Version 5.00 HKEY_CLASSES_ROOT\CLSID\{080d0d78-f421-11d0-a36e-00c04fb950dc}

Does the Cisco VPN client support PPTP connections? If not, you won't be able to use it to connect to RRAS (at least in it's default configuration)...

Another time where having a DFS would've helped out a bit... If you plan on adding additional servers into your domain in the future that will be fileservers, consider a domain root DFS and the file replication service (don't lose than Server 2003 manual yet!!! ). Your users will be able to access file shares on new file servers added into the DFS root without having to visit a new share (everything is stored as subfolders in the DFS root share), and the file replication service (NTFRS) can be used to synchronize files and permissions from one server in the DFS to another.

What was your resolution?

Start regmon (www.sysinternals.com) right before you attempt to recreate the problem, and then immediately after stop regmon logging. Take a look and see if you are missing the registry keys listed in the article you linked above (http://hidev.com/knowledge/listing.asp#95). If you're missing these keys, regmon should show you they are missing (when the parser comes across the code trying to access those keys, it should say "NOT FOUND"). It sounds like it's at least worth a try - and if you are unsure of what you're doing, just make a backup of the registry keys you're changing (as the article says) before fiddling that you can restore back if you get into trouble. It sounds like you've exhausted every other possible fix (I remember you made a similar post for this error some time ago). If you aren't willing to go into the registry and see if you can fix it, then you'll likely have to reinstall the OS.