cluberti

I've noticed that lines 01B0 and 01C0 may be incorrect. Can you post screenshots of the View > Partition Table and View > NTFS Boot Sector from diskprobe on that drive? Your first sector may be incorrect at either line 01B0 or 01C0, but it's hard to tell without the other data.

Well, not to be repetitive, but a network trace would confirm or deny that. Instead of guessing .

No - if drive recovery software sees the disk and your data, but XP says it's unallocated, you can almost be guaranteed that you simply have flipped bits in sector 1 causing it, which diskprobe can fix. It's just figuring out WHICH bits

Well, considering it's supposed to be a backup solution and a media server (and a basic one at that), I'm not sure how that is surprising.

One svchost.exe process contains the server service, which listens for inbound connections (this is normal if the server service is running). They "SYSTEM" process isn't really a process at all (in user-mode terms, anyway) - it's a representation of user-mode threads with kernel-mode components (basically, it's things running in kernel) - if you have applications on the machine with kernel-mode drivers (like a firewall, antivirus / antispyware, or backup software), this could be normal as well. Alg.exe is the Application-Layer Gateway service, and provides an interface for plugins to the Internet Connection Sharing service (so if you aren't using ICS, this is probably your firewall - I've seen ZoneAlarm listen on this port via alg.exe before). At this point, you don't seem to have anything nefarious on the box from what you've shown, so it would probably behove you to download something like wireshark and gather a network trace for 30 - 60 minutes, then save the network capture and open it up to see where all of your network packets seem to be going. That'll at least give you an idea of what's happening.

Run DiskProbe and follow the link I sent - if you have the "42" bit set (as in the steps in the link), you'll know what has gone wrong (and how to fix it). This is the most common reason for drives to be listed this way after a reinstall (it's not the only reason, but more than 50% of the time I follow this with good success).

Was the old SATA disk (that now shows unallocated) formatted FAT32 or NTFS? Also, was it created basic or dynamic? If it was NTFS, you could probably use diskprobe (from the XP Resource Kit) to hex modify the disk so that XP recognizes it properly again. It sounds like there's an invalid bit or set of bits on sector 1 that XP can't make out, so it shows the disk as "unallocated". http://thelazyadmin.com/blogs/thelazyadmin...asic-Disks.aspx

Moved to more appropriate subforum.

Sounds like it's time to run sfc /scannow on that machine - cscript.exe should NEVER give errors .

You've added both an x64 boot and install image, or just a boot image? I can't say I've run into this before, but there's a first time for everything .

I would ask that you please not double-post in the future, and thank you. From the forum rules: <Edit> The exchange of posts regarding the double posting have been removed in order to maintain thread readability. The forum runs smoother if these issues are raised with an appropriate Moderator via the report function and not discussed argumentatively within the thread proper. Thank you. </Edit>

How do you have your DHCP option configured for PXE? - Option 66 should point to your WDS server's FQDN: risserver.yourdomain.tld - Option 67 should point to the x86 pxeboot.com file: \Boot\x86\pxeboot.com By configuring this way, when an x64 machine connects to the x86 pxeboot.com file, it will detect the architecture and redirect to the x64 pxeboot.com file automatically. When this happens, x64 machines will see x64 boot options, but x86 machines will not. It sounds like you have your option 67 pointing elsewhere, or not defined at all.

Hmmm - script host is installed by default in Vista. If you go to a command prompt and type "cscript" (and press ENTER), do you get any errors, or cscript usage help?

That's very odd, although I have seen this before with 3rd party firewall software. Consider downloading ShellExView from nirsoft.net and disabling all non-Microsoft explorer shell extensions, and perhaps autoruns from sysinternals to disable all non-Microsoft items. If that works, you can start re-enabling things until the culprit is found.

Is this an RTM Vista install, or a beta or RC build? Also, are you forcing a location in your answer file, or are you installing the same language that the image was built using?

Could you please post the exact error you get? Your post is a bit too vague to help much at this point.

Don't think about it in "technical administrator" terms - it's the management that purchases things like this. Why? Because they see the bottom-line (saved money in time, and someone to choke if things go wrong, aka Microsoft).

I hope that's not a serious question - there are customers out there still running 100s of thousands of NT4 boxes. 4K for patches they can deploy to all those machines automatically, or pay admins hourly (at whatever rate) to do it manually, to all 100s of thousands of boxes (there were other alternatives, but not as easy as a hotfix). Which is actually cheaper?

Sounds like you didn't clean up DNS with the new information, especially the GC errors. Verify that your servers are indeed using the correct DNS information (and that your DNS information in all of your zone data points to correct servers). Otherwise, try to use replmon to monitor forced replications, and start by troubleshooting the errors there.

Yes - these were NON-security updates, and thus were not publicly released. Customers wishing for DST patches (whether W2K or Exchange 2K) needed to pay $4K USD to get them (NT4 and Exchange 5.5 were more expensive, BTW, as they were out of even extended support).

You're missing those files because .NET 1.0 does not ship on vista (although the placeholder folder will be there). You will need to actually install the .NET Framework 1.0 onto Vista to use it, although 1.1 is probably better, and apps coded directly against the 1.0 location are very, very rare (I can't think of one, but I'm sure someone, _somewhere_ did it once ). As to the other files, pxwma.dll and pxcpyi64.dll are both files from Sonic Solutions software, so if you don't have that installed I wouldn't think it would be a worry (or perhaps they don't install those files on Vista, and use some built-in .dll that now includes whatever those .dll's functionally provide - hard to say). And Dimm.dll is part of the Microsoft multilingual IME, which is part of Vista's multilingual interface components. If you don't have any non-local languages installed other than the language you installed Vista into, not having this .dll installed is also normal.

By default, all PCs in a site will sync via Nt5DS time with either a local DC in their site, or the PDCE DC if it exists in their site, and DCs will try to sync with the PDCE DC. The PDCE DC can be configured to be a reliable source without having to sync to another (actual) reliable NTP server, although it would be best to at least have one machine in your intranet that is running NTP software that does sync to at least a stratum3 server on the public internet, like one from pool.ntp.org. If you can at least do that, you can find your answer here. If you can't do that, you can set your PDCE up as an NTP server as well and make it the local time source via NTP to sync with itself, but that's a bit redundant. I strongly recommend either doing nothing (by default, the PDCE becomes the authoritative time source in this scenario), or have an actual sync'd NTP server somewhere on the intranet that the PDCE can sync with. You can find all the reg entries you need in KB223184. Good luck .

Because it wasn't free - it was $4K. MDGx should probably at least consider taking those patches down, as they aren't even privates, they're pay-for-fix hotfixes.

If they are on different networks, the routers/switches in between need to allow (and are configured for) DHCP passthrough/DHCP relay.

Well, from what we know it could be any number of things - the laptop's firewall is blocking the ping, the address resolved by DNS is incorrect, the laptop is not actually connected to the network, or the laptop is powered down or off.