adamt

You can still find Office 2003 SP3 at the MS update catalog site. You might also want to make sure that Windows 10 has the latest available servicing stack update.

Usually, with an expired password, you would still be able to login, but you'd be prompted to change it.

Are you sure the password is still blank? Could somebody have changed it? Once you get back in again, check your security log for event ID 4738.

On the HP ProLiant SmartArray devices I have used, the cache is disabled when the battery loses charge or registers a fault. This is done to prevent the loss of data in the event of a power outage. It's easier for HP to support a disk performance issue that they can just tell you to replace the battery for, than it is to recover a corrupt database. When the battery fails, or has no charge, event ID 1206 from Storage Agents will be logged to tell you about the battery failure. Event ID 1204 will also be logged to tell you that the cache accelerator module has been disabled.

It's set to "Ignore", and the "Make this action the system default" is checked.

Dear all, I am trying to run silent/unattended installations of NetBackup client 7.1 - which includes the driver wimfltr.sys. Unfortunately, that driver's certificate expired in 2008. According to that article, this can be ignored should not prevent installation - but unfortunately, it does. At least on some Windows 2003 SP2 x86 servers. They all have the group policy item "Devices: Unsigned driver installation behavior" set to "Silently succeed", and all have the "Driver Signing\Policy" registry key set to 00. But some are logging the following in the setupapi.log file: [2013/06/20 08:43:34 5780.1] #-198 Command line processed: "C:\WINDOWS\system32\rundll32.exe" setupapi,InstallHinfSection DefaultInstall 132 C:\WINDOWS\system32\drivers\Wimfltr.inf #-011 Installing section [DefaultInstall] from "C:\WINDOWS\system32\drivers\Wimfltr.inf". #W367 An unsigned, incorrectly signed, or Authenticode signed file "c:\windows\system32\drivers\wimfltr.inf" for will be installed (Policy=Warn, user said ok). Error 1168: Element not found. #-024 Copying file "C:\WINDOWS\system32\drivers\WimFltr.sys" to "C:\WINDOWS\system32\DRIVERS\WimFltr.sys". #W363 An unsigned, incorrectly signed, or Authenticode signed file "C:\WINDOWS\system32\drivers\WimFltr.sys" will be installed (Policy=Warn). Error 0xe000022f: The third-party INF does not contain digital signature information. When this happens, the installation halts, waiting for somebody to click OK. As this is an unattended installation, nobody will see this prompt unless they logon to the console (session 0). I can't find which setting it might be that is causing some of these servers to choke on the wimfltr.sys file, whereas others succeed. It happens on machines upgrading from the same previous NetBackup client versions, and with the same version of the setupapi.dll file. Apart from the resultant set of policy, local computer policy and the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing\Policy registry key, where else should I be looking to find out why some servers are logging "Policy=Warn" in the logs? Many thanks, Adam.

Just wondering - in your DHCP scopes, are you instructing the clients to use the old Win2k3 server as their primary DNS or WINS server? Can you try to validate the IP configuration of one of the affected machines? Test NSLOOKUP against all DNS servers and compare times?

There are many reasons why this might be. Firstly, as allen2 has told you, the space may be used up by pagefiles, shadow copies, hiberfil, etc - files which are usually hidden from the shell unless you configure it otherwise. Then, bear in mind you there's things like reparse points (junctions), compressed files, etc - see: Computing the size of a directory is more than just adding file sizes on Raymond Chen's blog, and the similar Windows Confidential article he wrote for an overview.

Hi, I've recently had an issue in which a customer application had bloated the HKLM\Software bit of the registry to 2 GB. It was 32-bit COM application running under a 32-bit dllhost.exe process on x64 Windows Server 2003, and was filling up HKLM\Software\Wow6432Node\Microsoft\EventSystem. I was able to use dureg.exe from the Windows 2000 reskit to find which bit of the registry was taking up all the space. However - I noticed that dureg.exe is (being from the Win2000 days) an x86 application, and so although it reported that it was reading HKLM\Software\Microsoft\EventSystem, it was actually being redirected to Wow6432Node. That didn't really matter in this instance, as it just so happened that the bloated key was under Wow6432Node. But what happens if you have a similar issue with an x64 application, filling up the registry in an area which a 32-bit application can't read? I can't find a native 64-bit version of dureg. I was looking at writing something to do the same sort of job, but the RegistryKey class doesn't seem to expose a 'Size' property. Any suggestions of how the size of a registry key (including all sub-keys and values) can be enumerated in C, C#, C++ - or better yet, any suggestions for alternative tools which would do the job? Thanks, Adam.

Do you have permissions to edit the \boot.ini file? And if you make changes to it using msconfig - does your boot.ini file get updated with them?

Dear all, I have one server environment which seems to be generating quite a lot of these events, mostly from Win2k3 SP2 machines: Event Type: Warning Event Source: Srv Event Category: None Event ID: 2012 Date: 27/08/2011 Time: 07:05:25 User: N/A Computer: WIN2K3WEB Description: While transmitting or receiving data, the server encountered a network error. Occassional errors are expected, but large amounts of these indicate a possible error in your network configuration. The error status code is contained within the returned data (formatted as Words) and may point you towards the problem. Data: 0000: 00040000 00540001 00000000 800007dc 0010: 00000000 c0000184 00000000 00000000 0020: 00000000 00000000 0000097b I'm 99% sure this is down to some Riverbed CIFS devices, which are making it appear that a connection is still open for business when it has in fact already been closed at the remote end. Anyhow - I know that the c0000184 signified STATUS_INVALID_DEVICE_STATE, and I've worked out that 800007dc actually just means 'this is event ID 2012'. What I'm wondering about is what the 00040000 00540001, and the 0000097b mean. Sometimes, instead of 0000097b, it is 0000097a. This doesn't appear to be a Win32 error code, and it looks nothing like an HRESULT or NTSTATUS value. Any pointers on what these values mean? Thanks, Adam.

You could download Process Monitor from Sysinternals, and run that, looking for what is accessing that key. Start process monitor with the /noconnect switch (c:\path\to\procmon.exe /noconnect) - which will stop it from instantly logging every single bit of activity from the second it loads. Add a filter: If path excludes "CodeASU1" then Exclude. Also, use the 'drop filtered events' option - to stop it from filling up your pagefile. Now tell it to start capturing events, and from there on, it's a waiting game to see which processes are touching that key.

Obviously, it's a bit late now, but I would have suggested looking for the following registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\ NoDrives (DWORD) = 1. If it's there (and not set to 0), Explorer will hide some/all drives from you. Full explanation of the key is at: http://technet.microsoft.com/en-us/library/cc938267.aspx

I sometimes find that I need to kill my rdpclip.exe process, then run it again to resolve RDP clipboard issues. There's one rdpclip per logged on user, so be sure you kill the right one. I have seen one case of a TS box which wasn't even trying to run rdpclip.exe. The problem was with the registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\ StartupPrograms = (String). HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AddIns\Clip Redirector\ Name = (String). On _most_ Terminal Servers, these string values are equal to “rdpclip”. The problematic one had them set to "fxrdpclp", which is some kind of Win2000 Resource Kit utility, and wasn't actually present on the server. You might be interested in this article, which explains a bit more about clipboard chaining, and why it's better in Vista/7/2008: http://blogs.msdn.com/b/rds/archive/2006/11/16/why-does-my-shared-clipboard-not-work-part-1.aspx

Only Windows (Win2000 or later) machines understand authorisation. Other OSes won't check for auth. before handing out IP addresses. If the DHCP server did not live on the same subnet as the clients, it would need to have had a relay or ip helper pointing traffic towards it - else it would only have been able to offer/renew IP addresses to machines on the same local subnet. I'm not sure how this could have corrupted your DHCP database, though. In any case - we have a script which runs weekly on all DHCP servers, saving their configuration and the details of all IP reservations. Should anything go haywire with the DHCP service, we would be able to quickly restore it. It also allows us to periodically review the IP reservations to see which might not be needed anymore.