cluberti

XP will recognize 4GB of __RAM__, perhaps you're getting confused with __VIRTUAL ADDRESS SPACE__...

Learn something new every day .

Is this W2K, XP, or W2K3? I ask, because depending on your version, you have to enable permissions differently in DCOM. If you aren't getting any other COM errors, though, I would instead suggest that you delete the registry key HKCR\AppID\{00020906-0000-0000-C000-000000000046}, as well as the "AppID" subkey under HKCR\CLSID\{000209FF-0000-0000-C000-000000000046}. Once you've done that, uninstall and reinstall Office 2000, and your problem should go away.

If you run msinfo32, you will probably see all 4GB of memory installed. Note that, as other people have said, this happens because the BIOS reserves memory for PCI-X or PCI-Express devices, the PCI bus, hot-swap memory (if available), and also video card RAM (higher-end video cards will shadow RAM into physical RAM, so if you have a 512MB video card, you could be losing 512MB of RAM to video shadowing). Check what msinfo32 says - if it says 4GB, then you're pretty much SOL.

Have you considered contacting your ISP or email host to ask them what you should be using for Outlook settings? If you formatted the machines, there's no magic pill to get that data back. Contact the email service provider and ask them what you need to do to reconfigure Outlook. As to your quip about not helping you, this part of the forum gets read and posted to very infrequently as you can see by perusing the postings in here - we have posts going back to October 20th, 2006, on the first page, whereas the Windows XP forum for example has posts going back to January 29th, 2007. If you wanted faster response, you might have wanted to place this in a more appropriate, higher-volume section of the forum, like, the Microsoft Outlook section.

Yes, it's not uncommon to see a second or two delay (especially if your antivirus has implemented script proxying, like McAfee and Trend do).

Those are private, or ephemeral, ports in that range (49152 - 65535). They could be anything requiring an ephemeral port (applications, kernel drivers, etc). You say that netstat -o tells you that the PID is 4? That would mean something running in the SYSTEM process (representative of threads running in kernel directly) has opened those ports. Who is the foreign address - where do those connections go?

Consider checking out print migrator 3.1 (printmig) from the microsoft.com download site. As to the shares, you'll either have to recreate them, or back up and restore the subkeys of the HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver once you change the machine name of the new server back to the old server name.

Remember that IE and the shell are inextricably linked, and the IE attachment engine is used when the shell accesses files (regardless of whether or not you're using IE or Windows Explorer).

It actually calls a shell32.dll api - here's a vb code snippet that can do it easily, and here's a vbscript snippet.

Are you sure that HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell points to explorer.exe? This can also be caused by other registry keys missing (used to see this a lot after installation of MS06-052, so I probably still have the .reg lying around).

Filemon description.

That means the laptop is probably the master browser, and you should make the media center machine a master browser instead. On both laptops, set the following registry values: Key: HKLM\SYSTEM\CurrentControlSet\Services\Browser\Parameters Value: MaintainServerList Data: No Value: IsDomainBrowser Data: No Value: IsMasterBrowser Data: No On the Media Center machine, set those registry values to Yes, and restart the computer browser and netlogon services on all 3 machines for the settings to take effect (this can take a bit of time, but should work shortly after service restart).

What if you manually configure the ISA server in the properties? Does it work if you enter the server name manually?

You can turn off the signing check in policy (gpedit.msc), but you'll still have to press F8 on boot and disable signed driver check to install the driver the first time. This can be disabled in x86 versions of Vista permanently in policy, but x64 does not allow this - you still have to press F8 and boot with driver signing check disabled to install the driver.

Create a machine object for the machine in question in AD, and you will see that in the properties of the object, there is a Remote Installation tab - you can do quite a bit in there to tell the machine account which image it should gather, and from which server (if you have more than 1).

What exactly is failing?

It's only a security risk if filesystem permissions let you do things on said filesystem you should otherwise not be allowed. However, there can be a perceived risk in that you can potentially search and discover files on disk that you do not have access to with your account. You most likely cannot do anything with these files, as their NTFS permissions will decide what you can and cannot do, but unless you've been explicitly denied the right to read certain locations on disk (and this is not a good idea on most places on the OS volume), it can look like a risk. As to external drives, all bets are off when it comes to searching those - most are not formatted NTFS (so no built-in security for the filesystem), and those that are formatted NTFS can travel from machine to machine, meaning security can be bypassed at another machine not under the admin's control. That I can understand.

6000.16386

First, my netcheck vb script: Dim sTestPath Dim intCount Set objFSO = CreateObject("Scripting.FileSystemObject") Set objShell = CreateObject("WScript.Shell") Set objVolatileEnv = objShell.Environment("VOLATILE") ' An UNC path here that will be available when network connection is in place sTestPath = "\\server\share" sTestPath = "\\RISSERVER\REMINST\Setup\English\Images\WXP\UNATTEND" 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 = 120 Then MsgBox "Unable to connect to network share for 10 minutes. Please notify your network administrator." Exit Do End If Loop ' share/folder available on server now, so continue End If Then, in my unattend.cmd file, I set the following variable (should map to the RIS Server's build folder if installed from a flat image): reg query hklm\software\microsoft\windows\currentversion\setup /v sourcepath > source for /f "tokens=3 skip=3" %%1 in (source) do set sourcepath=%%1 The very first thing I do in my unattend.cmd file, when configuring runonceex values, is to call the netcheck script before continuing (that way I know networking is up and I've got a valid IP, can get to the share, and things will work): SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx REG ADD %KEY% /V TITLE /D "Installing Applications (Stage 1 of 3)" /f REG ADD %KEY%01 /VE /D "Checking Network Connections" /f REG ADD %KEY%01 /V 1 /D "%systemdrive%\temp\netcheck.vbs" /f REG ADD %KEY%04 /VE /D ".NET Framework 1.1 SP1" /f REG ADD %KEY%04 /V 1 /D "%sourcepath%\UNATTEND\dotnetfx\dotnet11.exe /q:a /c:\"install /l /q\"" /f REG ADD %KEY%04 /V 2 /D "%sourcepath%\UNATTEND\dotnetfx\867460.exe /q" /f REG ADD %KEY%04 /V 3 /D "%sourcepath%\UNATTEND\dotnetfx\886903.exe /q" /f ... and on, and on... The reason I do it this way is because mapping drives during runonceex is frought with danger, but accessing UNC paths seems to always "just work".

The only reason I'd want to test it is because explorer.exe gets slow only for a few reasons - 1, disk fragmentation; 2, file system filter driver I/O backup issues (antivirus, antispyware, backup software, firewall filters); 3. malfunctioning explorer shell extensions; and 4, hardware problems.

The only problem is, what is causing that to execute? *Something* had to put that in there...

It's the same for Business. It's actually only when using a KMS server where this can get dicey, but for retail or MAK keys, it should work on both.

Well, that hex value is either "STATUS_UNEXPECTED_IO_ERROR" or "ERROR_PIPE_NOT_CONNECTED" - since it's complaining about I/O, I'd say that it's the first coming from ntstatus. Are you using an .iso, or have you burned media? Or is this "gold" (hologramed) media?

Yes - keys for Vista are SKU-specific, but will work on both x86 and x64 versions of the OS that match it's SKU.