cluberti

It would help to know how you are calling them, and what the .reg files actually contain. There could be something simple here, but your post lacks data.

Try calling this vbscript instead, as your batch file will run the vbscript and only continue when the network drive is available and mapped (useful when waiting for a slow wireless net connection to fire up too): Dim sTestPath Dim intCount Dim objnet Set objFSO = CreateObject("Scripting.FileSystemObject") Set objShell = CreateObject("WScript.Shell") Set objVolatileEnv = objShell.Environment("VOLATILE") Set objnet = CreateObject("Wscript.Network") ' An UNC path here that will be available when network connection is in place sTestPath = "\\pentium4\unattended intCount = 1 ' test on volatile environment variable to avoid running logon script ' if the user has already run the logon script. If Not objVolatileEnv("LogonScript") = "Done" Then Do Until objFSO.FolderExists(sTestPath) ' sleep 5 seconds WScript.Sleep 5000 intCount = intCount + 1 If intCount = 60 Then MsgBox "Unable to connect to network share for 5 minutes. Please notify your network administrator." Exit Do End If Loop ' share/folder available on server now, so continue objnet.MapNetworkDrive "U:", "\\pentium4\unattended\Apps\Firefox","True","domain\user","password" End If Watch out for word wrap there - the whole objnet.MapNetworkDrive section is one line, not two (as it may appear here on the boards).

Exchange is very poor at memory management, and also generally requires the use of the /3gb switch to make sure it's databases don't corrupt due to lack of virtual address space. This, however, halves the amount of kernel paged and nonpaged pool memory resources, as well as drastically limits the amount of available system PTEs required for memory operations. Domain controllers require a lot of process address space and kernel paged and nonpaged pool resources, and also can require a good number of system PTEs for authentication and replication operation, especially lsass.exe. If you're running Exchange, you are going to generally be using up lots of virtual address space (and thus RAM), as well as a good amount of kernel memory and PTEs. When running Exchange on a DC, something has to give when they both need resources - and it's usually your server, either when lsass.exe crashes and the server bugchecks or automatically reboots (because system security is lost when lsass.exe quits), or you start to get random Exchange database corruption due to lack of resources available to Exchange. This happens so often that I wonder why this isn't more well-known, but I'll state it here for all - do NOT run Exchange on a DC, ever, unless it's SBS. SBS has been modified to do different things and run some things that a normal Windows server is NOT tuned to do. There are reasons that there are limitations as to why we only allow up to 75 users in an SBS domain, and it is not (as you may start to understand as you run a DC, Exchange, and ISA on an SBS box) some draconian number meant to bleed you dry - it's actually somewhat technical in nature, as you can hopefully understand. SBS can only be tuned so far before you have to move away from the one-size-fits-all SBS server into more specialized servers that will run better when separated (like separate DC's and Exchange servers). SBS does a lot of things, and does them fairly well, but it does none of them very well like a dedicated server would.

Run this vbscript in a MACHINE logon script configured in a GPO in AD: Set objWshNet = CreateObject("WScript.Network") ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // Configure basic script variables strDomain = objWshNet.UserDomain strComputer = objWshNet.ComputerName Set objGroup = GetObject("WinNT://" & strComputer & "/Administrators,group") ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // Configure to add a domain user to the Local Administrators Group strUser = "useraccounthere" Set objUser = GetObject("WinNT://" & strDomain & "/" & strUser & ",user") ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // Configure to add a domain group to the Local Administrators Group 'strUser = "domaingrouphere' 'Set objUser = GetObject("WinNT://" & strDomain & "/" & strUser & ",group") ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // We actually add the user or group here, if not already a member of the local ' // Administrators group: If Not objGroup.IsMember(objUser.ADsPath) Then objGroup.Add(objUser.ADsPath) End If This will add a domain user (or group) to the local Administrators group on the target PC when the PC starts up - since this runs as the SYSTEM account, rather than a non-admin user, it can add users to the local Administrators group when the machine is starting up, making that user (or group) a member of the local Administrators group before they log on. If you find that you have lots of mundane admin tasks like this, you should seriously consider learning vbscript (and ultimately higher-level programming languages, but at least vbscript). Good administrators are generally, as a rule, also good programmers .

Is the ICF/Firewall service set to disabled or manual? If the service isn't running, your firewall won't be either.

It is possible, but we'd have to have perfmon data of both machines showing disk queue length and disk throughput numbers, memory numbers, processor data, etc. while doing the exact same steps to determine if this is really the case. Anything's possible .

I don't know if there'll be an update to this, but I can say there is not an update as of now.

It's actually the HP daemon (hpgs2wnd.exe) that's causing it in those scenarios, and it comes with LOTS of different HP software, apparently. Deleting it from the Startup folder and the Run registry keys usually fixes it.

Since the designer(s) of the webpage are responsible for whether or not an activex control is used to embed video files, probably not. And the compatibility patch expires this summer.

You don't, for the most part - that's part of the new ActiveX update that was installed on your machine with the rest of the April Windows updates. It's a behavior modification in the way Internet Explorer handles ActiveX controls due to the Eolas patent lawsuit. There are ways to disable it until June, but after that this is expected behavior from now on.

In most scenarios this is caused not by verclsid.exe itself, but a shell object or extension that is loading a COM object, sometimes in Office, sometimes in Windows Explorer, sometimes even in IE, that causes verclsid.exe to run (to check the security before instantiating the COM object). Unfortunately, it's hard to say which software is causing it, but disabling shell extensions with shellexview and rebooting is a good test, as is removing any software that uses COM objects as handlers (like HP's Share-To-Web application, for example). In some cases, removing antivirus software also resolved the issue when the issue was affecting Office and IE. This is a bit of trial and error, unfortunately, and you can always uninstall the patch and wait for this to be fixed, if it becomes a big enough issue for a re-release of the patch. It can sometimes be easier to find if you can reproduce it at will - load up Process Explorer, reproduce the problem, and see what was the last binary to load before verclsid.exe. Uninstall the patch, reboot, load up process Explorer, then run through the repro steps again and see what loads up - usually you'll see something load up during the repro steps the second time that didn't load up during the first run (when verclsid.exe kicked in), and this may help lead you down the path of the app causing the issue.

Thanks

Just search the microsoft.com website and technet - they are both very well documented there.

Yes, it appears that, for the most part, the new update from today includes the fixes for the issues with the previous (February) version of the update. I was told this was to be the case, but I can't say for certain that everything reported on the old update has been fixed, so time will tell.

If the Windows 2000 server is a domain controller, the user accounts aren't actually local to the machine, they're in the AD. Simply do the following to keep everything humming along: 1. Install the DNS server component on the 2003 server 2. Configure DNS on your 2003 server (using the same as the 2000 server's configuration), and appending the 2003 server's DNS information 3. Add the 2003 server to your 2000 domain via the dcpromo command 4. Transfer the FSMO roles (via ntdsutil) to the 2003 server 5. Make the 2003 server a Global Catalog server Now, just wait a few days to make sure all is well, then run dcpromo the Windows 2000 server to remove it from the domain. All domain information, including accounts, will still be intact.

Unless it's SBS, don't run Exchange on a DC - ever.

I would think that would be a very good solution for a userbase of that size, as long as 280GB of storage space is 1) adequate for your userbase's file storage and 2) can be backed up completely and regularly, either to tape or another storage medium.

Normally, that's a cluster. However, in AD, that's accomplished by having multiple DCs, multiple DNS servers, multiple GC servers, and spreading out the FSMO roles as necessary.

Not long term - Public folders are going away with the next version of Exchange.

Even that can be problematic (you're going to be doing some ADSI surgery depending on the age of the backup), and it's always a last-resort step. I'll still take it over nothing anyday, though .

This is a pretty obvious bugcheck, and Mordac hit the nail on the head - it's spelled out for you in the bugcheck's analyze -v statement. Get yourself a new hard disk while you still can get your data off of it!

The "real" value of c0000005 is an Access Violation, due to lack of permissions. You won't see buffer overruns giving c0000005 errors on boot that correlate to buffer overruns. During running OS, yes, but on boot, no. Those are specific during boot, and some code (likely a driver) is access violating in kernel, which is what the STOP code is stating (cryptically, without a dump file to review, but that's what it is).

You get rid of userinit.exe, most startup processes you'll need for network connections to function will cease to work, for starters. Why would you want to change or delete that process, btw?

System Properties > Advanced > Startup and Recovery Settings > uncheck "Automatically reboot".

Ryan is absolutely correct - this isn't an "update" to IE, per se, it's a "behavior modification" caused by the Eolas patent lawsuit that was lost. If you want to blame someone, blame Eolas (or the patent system) - Microsoft is doing what it has been court-ordered to do. A real solution would be to not use ActiveX controls at all, but I doubt people will stop using them anytime soon in webpages.