cluberti

If you're sure it's not a domain group policy doing it, you can follow the steps in KB 313222 to revert local security to base install defaults.

Glad to help

Setupp.ini changes OEM vs Retail vs VLK, not HOME vs PRO. If the original poster does not have his media, there are several legal (and some not so legal) means of obtaining the XP CD. The only thing I can condone here at MSFN is contacting the computer vendor or Microsoft to provide you with replacement media - anything else would be outside the purview of the board rules. l0cke - suggestion to you to contact the hardware vendor of your PC, or Microsoft, to see if they'll send you replacement media. Otherwise, you'll have to resort to other means to get the media - borrow from a friend, etc.

Not a problem - good luck

This can be found by searching the Microsoft site fairly easily: http://www.microsoft.com/downloads/details...;DisplayLang=en

You should consider reading this article as well: http://support.microsoft.com/kb/298402/

Why exactly are you using NT4, btw? Is there some reason you cannot use at least W2K?

That appid belongs to Urge - something is loading in Urge in WMP 11. Perhaps a reinstall of Urge for WMP 11?

USMT was designed to do exactly this, and it's scriptable.

Well, you could reinstall the service pack and all subsequent hotfixes.

When I went to the links you posted on FileHo, that's the message I got.

Do you perhaps have autoarchive enabled? By default, your items get autoarchived to .pst files every 2 weeks...

What is basically happening is that your system's BIOS has reserved memory for the PCI bus, a PCI-x or PCI Express bus, and other system components. It then reports to Windows that the 4GB boundary is actually lower that 4GB so that Windows doesn't attempt to use the reserved RAM (you will probably see all 4GB of RAM if you run msinfo32). Note that even after adding the /PAE switch, you won't see anything more than ~3GB of RAM, because the BIOS has told Windows that the 4GB limit is not at FFFFFFFF, but lower. Unless you have an OS that can see above 4GB of RAM (x64 versions of Windows, 2000 Advanced Server, or Server 2003 Enterprise), you will still not see any more than 3GB. If you do start > run and type msinfo32 and click OK, the system will do a WMI check on the installed memory (not available, but installed) - and assuming your BIOS indeed sees all 4GB installed, you'll see ~4GB of RAM in the msinfo32 report. There's not much you can do other than run an x64 OS, or install a version of Windows that can actually use the /PAE switch to see more than 4GB of RAM if you want to use it all. It's not a Windows problem, it's a BIOS issue. And please don't use the /3GB switch unless you have applications that can use more than 2GB of virtual address space - you're hamstringing your kernel into 1GB of address space, and that's not a good idea unless you need to do so.

sfc /scannow or a repair installation.

Deleted because of abuse - perhaps you could post the AppID value from the CLSID entry? Or even look it up in the registry (search the AppID value) - that should come back to an .exe or .dll file in the registry.

Good luck - if wireless doesn't work out, I second fiber - it's cheap, you can run it on utility poles (after getting the appropriate permits, at least here in the US), and it's usuallly faster or at least as fast as your network's rated speed. Switches with GBIC ports are usually not too expensive either .

I'm assuming you copied all of the .sys and .inf files from your Intel driver cache to the \i386 folder of the flat image, restarted the binlsvc service, and the error still persists?

I could insert a crack here about running AD instead of Novell, but that'd be useless. Since I'm not a Novell guy (haven't been for over 10 years), I really can't comment further. I'm assuming XP's Novell client isn't up to it on your Novell network?

If this is a 32bit system (and I hope it's not, given 16GB of RAM), try the /maxmem option in boot.ini to force it to 4GB of RAM to see if that improves anything - and do NOT, under any circumstance, run a file server with the /3GB switch, and if at all possible avoid runnign a /PAE kernel unless hot-add memory or hardware DEP is required. This will DRASTICALLY cut down on available PTEs (with the /PAE switch) and kernel paged pool and nonpaged pool memory (with the /3GB switch), both of which are very important kernel memory pools you need on a file server. Running either is a very, very bad thing for performance on a file server. Also, make sure you're using the latest bits for ntfs.sys and storport.sys from Microsoft, and the latest SCSI or HBA drivers from your storage vendor (make sure you use the version of storport.sys they recommend, if they do recommend a version - and some do). One other thing that can absolutely sap a file server of it's effectiveness - real-time antivirus and antispyware scanning. Unless you'll be fored for not running those, get them off of a file server immediately. They're extra (unnecessary) overhead on a machine doing that kind of I/O (especially considering the client is likely also running the same darned A/V and antispyware package!!!). If this box is 64bit, consider making sure your disk drivers are current and (if possible) WHQL certified, and you aren't running real-time antivirus or antispyware software (see above).

Yes - you need static entries in the forward (and possibly reverse) zones for company-site.com on the SBS server. What happens when you give your internal domain a public name is that AD clients then assume that all DNS queries against that TLD are local. If the servers are NOT local, the lookup will fail until you add a static entry for every host that is not on the SBS network, but has it's TLD as company-site.com.

No, I understand completely - users on a TS can see printers in other sessions and probably print to them. And I told you why this can happen - make sure you aren't doing either of these things on the client machines or the Terminal Server itself, because this is a permissions issue entirely.

Moving to more appropriate forum.

This has been asked here before, and here is what was posted as a fix last time: http://www.birdforum.net/showthread.php?t=59608

Could you post your last session .ini file?

Well, we've got a real problem - dllhost is crashing, but it's doing a 1st chance exception waiting on a thread that's already terminated (and isn't in the dump). Here's what I was able to cull from the dump. Here's the active thread in the dump - notice that we're waiting on a critical section in ntdll.dll (an API .dll, so anything could have called this, unfortunately): And here's the dump of the actual critical section data that was in the dump - notice that the owning thread is c64, but as I stated before, it's terminated already so I cannot see what the heck it is: dt ntdll!_RTL_CRITICAL_SECTION 77685340 +0x000 DebugInfo : 0x776857a0 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : -10 +0x008 RecursionCount : 2 +0x00c OwningThread : 0x00000c64 +0x010 LockSemaphore : 0x00000208 +0x014 SpinCount : 0 dt ntdll!_RTL_CRITICAL_SECTION_DEBUG 776857a0 +0x000 Type : 0 +0x002 CreatorBackTraceIndex : 0 +0x004 CriticalSection : 0x77685340 _RTL_CRITICAL_SECTION +0x008 ProcessLocksList : _LIST_ENTRY [ 0x77687248 - 0x77685318 ] +0x010 EntryCount : 0 +0x014 ContentionCount : 5 +0x018 Flags : 0 +0x01c CreatorBackTraceIndexHigh : 0 +0x01e SpareUSHORT : 0 Critical Section is LOCKED, with 1 Waiters So, it's your typical critsec abandon crash, but the dump isn't entirely of help (it shows the crash, but not the culprit who caused it). Thankfully adplus gathers log data, and I did find that the crashed dllhost was started with the GUID {AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}, and the other dllhost was started with the GUID {CD84562B-B3E6-4D39-9E4F-9C1A1FCE4DA7}, neither of which I can find any information about. Perhaps you can search your registry and see what these GUIDs correspond to (especially the first one)? A dllhost.exe process won't be spawned by a Microsoft app, so perhaps the GUID will tell us who spawned the dllhost, and that will likely tell us who owns the component that caused the critical section abandon and crash of dllhost (since you were doing WM stuff I'd say it's a codec, but I can't be entirely certain).