cluberti

Happy birthday to Zxian today!

Because Windows doesn't know anything about RAM or a paging file itself, the NT memory manager does all that translation. Windows deals in "Virtual Memory" (VM), and the memory manager maps it's pages to pages in RAM or the paging file (or both). It lists "VM" because that's all it understands.

For starters, the ISO 3166 language code you need in UILanguage is en-GB, not en-UK (there is no en-UK, hence why it's asking you). Also, in the UnattendJoin section, the username should just be Administrator, not domain\Administrator. That's the reason there's a DOMAIN value - you don't need to add it twice (and shouldn't). In all, there seems to be quite a bit missing here from what I would consider a "complete" answer file, although this will do what you've asked it to do if you change some of it as per above. Remember, WSIM validation validates that you've not added anything in the wrong pass, or have typos in your tags - it doesn't validate the contents of the tags for validity, just the layout.

Don't double post. This thread is closed.

Sounds like some bargain basement switches there - a 100Mb client shouldn't knock the switching backplane down to 100Mb for ALL ports. That's just crazy talk .

Considering the benefits of serving a static page versus dynamic content, it would be well worth figuring that out. As Coffee said, it's a compression algorithm for compressing content from the webserver to the client browser. Given you're serving about 34K of data, gzip compression should yield about a 75% (in some cases more) reduction in size transmitted from the server to the client. Couple your server with no compression and the fact that you've also told the client not to cache ANYTHING from the webserver, you're unnecessarily spending time re-serving UNcompressed data to a client EVERY time they visit the site - from the headers visiting your site this evening: HTTP/1.1 200 OK Date: Wed, 14 Apr 2010 05:50:30 GMT Server: Apache Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Pragma: no-cache X-Pingback: http://skeetabyte.com/xmlrpc.php Set-Cookie: PHPSESSID=p1j9plhvn47a6m8u5b5e57jif1; path=/ Set-Cookie: wassup=MTdmMGQxYzJiMTY2NDM2ZTI3YTM1Yzg0YWFkZDgwMzE6OjEyNzEyMjY5MzE6Ojo6MjA5LjY4LjEuNjM6OnJ1aXMucGFpci5jb20%253D; expires=Wed, 14-Apr-2010 06:40:31 GMT; path=/ Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 125K isn't a LOT of javascript, but given the site's design most browsers won't start displaying the page until the javascript has been downloaded and compiled as it's all in the page HEAD. Someone on a slower connection will very likely see page load delays, as would someone visiting the site while the server running it is under load. Compression and caching - if you aren't changing the content too much (and things like images and javascript aren't changing), it would be best to allow caching at least for a day or so, along with implementing compression. There are at least 1371 sites hosted on that server alone that matched a reverse-IP lookup to the server hosting your site, so the fewer resources your site requires to actually serve content, the better.Consider using http://ismyblogworking.com and/or http://redbot.org to get more info about your blog, and hints as to what else you can do to make it more efficient.

So you want BSD + Lynx then, right? .

Sysprep is fine, as long as the apps are fairly self-contained. What I mean by that is that apps that require hardware drivers specifically (like card readers, biometric apps, etc) would be considered "install dependent" and require both the app and the driver. Apps that simply install to program files and dump some info under HKLM\Software in the registry will likely have no issues at all after sysprep. I still don't recommend sysprep simply because you "lock" that image, no further updates and patching without deployment, and installing from a flat image with RIS or MDT 2010 and WDS is very easy. However, if you really do want to sysprep, in general it will work just fine. As to the original question about domain joining, sysprep removes almost all machine-specific information during it's generalization of the installation, including any domain information. It would be best to remove a machine from the domain before capturing it, or not ever joining it to the domain at all before capture if possible.

Set the mode and vid values in the registry for icons? Name Mode VID Icons 1 {0057D0E0-3573-11CF-AE69-08002B2E1262}

It *does* count any posts you delete, however, until the trash is emptied. This is not done often, so this can also account for post counts that might seem incorrect.

Sounds like a memory error on the "broken" switch, honestly - we had a Cisco that was doing the same sorts of things when spanning tree was enabled. Some of the internal memory was bad, and the switch was replaced.

Your disparate topics have been consolidated here. Please do not cross-post or double-post, wait for a response. If no one has responded in 24 hours you may bump a post as per forum rules, but double-posting and/or cross-posting is not something we approve of here. Your post will be seen, there's no need to flail about in multiple forums.

Works here, but I'm not using a tool to slipstream driver updates. I wonder if there's some correlation with doing it with a tool like 7Customizer versus using dism manually.

Windows knows which drive and controller in the SCSI chain it was installed to, and unless you "remove" that information with sysprep before you image an installation, you'll have to go and edit the boot.ini file to point to the new location. There's no guarantee the latter will work, although it should - the proper way to move a Windows install (if things aren't staying *exactly* the same between the two machines during the move) is to use sysprep to prep the system to be moved.

As long as you're not going to do a DoD wipe every month, doing it once or twice isn't really that bad. I've done it many times (not on the same drives, of course) without any issue. In fact, using one pass via DBAN (assuming you're not worried about someone "finding" data on the drive, as you're the one who will be using it once the disk wipe is complete) should be sufficient. I've had mixed luck with HDD Erase - it almost seems dependent on the machine's controller if it is going to work properly or not.

You probably could have achieved the same results by re-registering a few binaries (like shdocvw, shell32, and perhaps ole32 and oleaut32). IE doesn't control it, so what you did during the upgrade was to verify / change the registry for the installed components, and re-register all the dll's. You probably could have just done the latter and fixed it as well .

Well, if you're sure it's not bogged down (and it appears not), what does process monitor show you the system is doing while you're waiting? Anything?

The problem is, the Pointer Acceleration options you mention are not a default Windows option, so if you've had them in the past they were not coming from the standard Microsoft PS/2 or USB mouse driver.

I think the problem is faronics installs a boot driver that loads before windows - although imaging should have made it go away, I would think. If you open a cmd prompt and run "set devmgr_show_nonpresent_devices=1", then "start %systemroot%\system32\devmgmt.msc", then click View > Show Hidden Devices, did it leave any drivers around that the new OS is picking up perchance (or any other odd/nonexistant drivers, especially under non plug-and-play devices)?

Sounds like the password complexity policy is enabled.

Hm - if you can connect to the AD and create objects (but not reset passwords), I doubt it's actually a DNS issue. Sounds more like a kerberos or permissions issue, although I've not seen this particular one before. What happens if you set it's primary DNS to it's public static IP (rather than localhost)?

Worked for me in a VM today - I had to have created and formatted the partitions before I ran setup (WillWipeDisk is false here), but I had Windows 7 installed on the only partition, and it was M. I dunno what you did or didn't do, but it does work. However, it's an awful lot of work for a cosmetic change that I would still recommend you do reconsider. There have been Windows updates in the past that fail if Program Files isn't on C:\ or D:\, for example, and while none have come across for Win7 yet it's not entirely out of the realm of possibility that it will happen at some point in the future. Unless you absolutely must run on a drive other than C: or D: (like a Citrix TS server running on M: or U:), it really is wise to use one of these two letters "just in case".

I see what you did there . Anyway, I happen to have a copy of said XP installation media as I had researched a bug specific to a Portuguese localized install, and it was a VLK install I had - I checked, and it matches this PID.

Are you *sure* it's the same key, without any typos / whitespace at the end of the line / etc? Also, what happens if you use the same winnt.sif in the i386 folder of a non-nLite'd install? The only reason it's asking is because it didn't like the key - as to why, I cannot say for sure without a debug.

Those errors are important, but the text simply means that the proper .dll information isn't registered properly or doesn't exist on your system (which is probably a hint in and of itself as to what the problem is), hence the generic "no text for this error" text in the event viewer. However, the MSI log *does* give us a clue as to what's wrong - the MSI error thrown in the log is here: MSI © (10:0C) [02:01:44:634]: Attempting to enable all disabled privileges before calling Install on Server MSI © (10:0C) [02:01:44:634]: Connected to service for CA interface. MSI © (10:BC) [02:01:44:644]: Closing MSIHANDLE (1) of type 790542 for thread 776 MSI © (10:08) [02:01:44:664]: Note: 1: 1719 It is indeed only *partially* registered correct (or appears so to the client-side msiexec binary when attempting to connect securely to the MSI service executable) as referenced by the above. Assuming you did do the following: - msiexec.exe /unregister - msiexec.exe /regserver - Gone into the registry under HKLM\System\CurrentControlSet\Services\MSIServer and verified all of the reg values here match a "working" server (if not, export this key, rename the .reg to .txt, and post here, and we can take a look). One of these things is incorrect on the system, according to WHERE it's failing (the installation routine handle hand-off from client to server service). The fact we have a log file is promising, but the fact we have event viewer errors and a failure here means the service registration information is munged somewhere, somehow. The above *should* fix it, technically, but if not export the key and we'll check.