cluberti

It was posted on a technet blog on January 1st for the new year, and then reposted again the 4th with some changes (updated article here), hence why it's showing up again everywhere. I would agree though, if someone posts something useful like this for some folks that you personally do not like, keep the thought to yourself. If there's an issue with a post, that's what the report button is for.

First, please read the forum rules again, specifically rule 2.a on post bumping. Second, I would suggest that you consider reading about integrating drivers using DSIM (because otherwise you need to use the old $oem$ structure and a DriverPath in your unattend xml file). There are very good instructions on Technet about doing this, as well as good posts here on MSFN about DISM and drivers if you want to search. I'd suggest asking your application questions in the Application Installation forum section (best place for those questions, and they're not really related to Windows 7 at all), and if you still don't want to use DISM to integrate drivers ask about doing it via an unattend file and the $OEM$ folder structure in the Unattended Windows 7 section. As to the hosts file, I have to agree with MrJinje - this could be done via a file copy from $OEM$, but placing it directly into the WIM would be just as easy. Again, if you want to use the $OEM$ folder structure and an unattend file, post the question in the Unattended Windows 7 section along with your driver questions.

If you follow this, it shouldn't really matter what language you're using.

Agreed - I remember when a friend of mine got a new dual-core machine years ago, and we worked on moving his retail XP install over to it. Until I removed Tiny, it wouldn't boot and would bugcheck unless we removed it from safe mode after disabling the driver in HKLM\System\CCS. It appears that versions of the Tiny firewall up through 2.0.15a, until Kerio took over and redid some of the code at some point for their later 2.x versions, have issues on most dual and multi-processor machines (OS notwithstanding) and newer Intel CPUs with hyperthreading (read: CPUs after the P4 line), which means there are timing issues and thread protection issues with that codebase, and it is indeed NOT threadsafe (even though it was claimed to support multi processor systems, it's definitely not good safe thread-protected code). Also, Tiny 2.0.15 and older were suspect to a SYN flood attack bug and a DDoS issue that would consume 100% of the CPU time in the system. There was a security bypass issue in Kerio 2.x versions of the replacement firewall based on the same code, and although Tiny has no secunia advisories at all it stands to reason the issue is likely to have existed in TPF 2.x, given Kerio's use of that codebase (and same developers, basically) for future Kerio firewall product versions. You have to remember that the product dates it's lineage to WinRoute Pro, which was released for 9x and NT back in 1998 - when Sunbelt took on Kerio and their products (and thus the WinRoute > Tiny > Kerio FW code), they decided NOT to re-release or to fix/backport anything to the 2.1 codebase for Kerio, because the code was old and it would have taken them too much time and effort to make it work properly on newer systems (heck, WinRoute and older TPF versions still used drivers compatible with DOS-based systems running Win9x). Couple that with the fact that Tiny's been dead for a long time (and Kerio too), unless there's absolutely no other alternatives for you, I'd look into a newer, updated, and more secure firewall product, otherwise you're going to be running with one processor disabled if you absolutely must run TPF. There are lots of good alternatives out there (free or otherwise), so it's worth considering at this point.

Correct - Win7 syncs with the hardware clock on boot, and then will use either the hardware clock or an internet time server to continue synchronizations over the course of being up and running. If you aren't using an external time source, that means w32time is using the hardware clock - thus if you're skewing, it's your hardware. Suggestions of using a time server at regular (somewhat short, perhaps every hour or so) intervals isn't a bad idea, and it's cheaper than a new motherboard too. For reference, Red Hat (and Fedora, and most linux distributions at this point) use ntpd for keeping a clock in synch, and it will check this every 1 - 17 minutes, depending on your connection, the amount of skew between what the time "should" be and what the system is reporting, and the quality of time at the time sources. Given that Windows' time synchronization (since XP) in a workgroup/home machine setting is once per week, this could explain why Windows skews so much, and a linux OS little or not at all. If the OP was to change the scheduled task for setting time from once a week to every 15 or 30 minutes, to more closely match ntpd, there would probably be no issues at all under Windows either.

Possible, but why not just use oscdimg to create the ISO? vLite might work, but it isn't necessarily the best option if you just want to extract the ISO, make a change, and re-ISO the source.

Yes, if it's an OEM copy you would need to do a clean install (hence OEM - meant for new PC's only). If you swap it for a retail version, you can upgrade or do a clean install. As always I'd recommend a clean install from one NT-based OS to another, especially from 2000 > XP, but if you have a ton of customizations you may want to shell out for a retail copy and try the upgrade (after a system backup, of course, just in case it all goes south).

In that case, consider this project: http://www.msfn.org/board/imagex-hta-win-p...64-t138048.html

To create a boot.wim PE image, consider looking up how to create one on Technet. As to the image itself, it's only valid for the exact machine and hardware it was activated on, and you won't be able to take it anywhere else and use it, just fyi. Also, if you have a running system you want to back up, just use Windows backup (it has a PC backup option) - you can restore this using the regular Win7 install media later if you need to (you can only backup to a network in Professional and up, but you can backup/restore ANY version of 7 to a non-network location with any version).

The OP said he had to register online within 3 days because of a hardware change (but in this case triggered by an OS reinstall), and given that registration is indeed not mandatory, the OP meant activation and we were responding in kind.

This was a known issue with SP1 and SP2, especially for folks who used tools like vLite to integrate/slipstream the service pack. Doing this leaves the CBS engine in a state where you may not be able to apply the next service pack, and you may also have issues with other updates that use the CBS engine as well. Given that Microsoft only supports the method where service packs are actually installed on a running OS and not slipstreamed (the best we can do supported is the reverse integration / reimage method if you want installable updates and don't have access to newer SP integrated media), this isn't really surprising. The updates assume you installed previous updates a certain way, and if you didn't, things can break.

That could very well be, but that has nothing to do with the WEI scores .

The Technet guide should be all you need. Assuming you're doing this from a machine with the WAIK installed, you should be able to follow this to make an amd64 PE image.

If you're nuking your disk with DBAN (and subsequently every sector has been overwritten) and you still have Win7 trying to boot, that would indicate that you have the MBR with the bootsector for Windows 7 on another hard disk, because once you've used something like DBAN to overwrite all the sectors on a disk they should literally be completely zeroed. The BIOS hands off booting to the hard disk to a specific sector location, so if DBAN actually overwrote the disk it *should not* have any bootloader data for the BIOS to find. Again, this almost sounds like you have multiple hard disks in the machine, and the Win7 bootloader isn't on the disk that Win7 installed to as the OS volume.

Moving this from unattend to customizing windows.

No, you are correct - but XP Mode includes a license for XP, whereas using a 3rd party does not (you have to bring your own). It's not a huge expense, but it's not free either.

Without a last_session.ini attached, I can only guess you removed something necessary. Since that probably isn't any more helpful than your question asking for help, attach your last_session.ini file to the thread and someone can take a look.

1. Did you slipstream the SP3 onto an RTM source, or one that already contained a service pack slipstreamed into it? 2. Did you slipstream SP3 into your source from a Vista or Win7 machine, or did you do it from an XP machine? 3. Is your disc using an unattended setup file? For #1, if you slipstream SP3 into an RTM source, you *cannot* bypass the product key screen. For #2, you must slipstream from a Windows XP machine, otherwise product key issues can occur and the installer can get into a position where it won't accept any keys, valid or not. For #3, if you're using an unattended file to drive setup in any way, you must provide a product key in the unattend - otherwise, you will get prompted, and there's no real way around that either.

No Aero theme (means no taskbar peek, etc) No multiple user switching - one one can be logged on at any one time No multimon support No DVD playback support out of the box (you can install a 3rd party codec, of course) You also don't have things like domain support, streaming media support, or XP Mode or Media Center, but I figure those are obvious. Given that there's no real overhead difference between Starter and at least Home Premium, I'm not entirely sure why you'd run 7 Starter unless it came with a netbook (in which case it'd make some sense).

No, Patriot.

What specifically are you trying to do? Vista and Server 2008 use a WinPE image to boot the setup engine, and that engine uses the setup.exe routine to place the .WIM image down onto the disk (amongst other things). There's no more text setup portion, so what specifically are you trying to accomplish? Are you trying to get multiple versions of Windows Vista or 2008 onto one bootable installation DVD?

You can run the test manually from a cmd prompt to see what it says - not much help now that you've gotten past it, but I've seen this a number of times on SSD drives where it'll cap it at 5.9 until a defrag.

Without taking it apart and looking, it's hard to say. Linksys/Cisco don't make the info publicly available, and it's not found whilst doing a quick search (although I did find you asking the question on multiple forums, but that's about it). Again, short of asking Linksys/Cisco themselves, I don't think we can answer this unless someone has one and doesn't mind taking it apart.

Honestly it just sounds like a crappy drive. Recently picked up a Dell Latitude E4200 with a Samsung MLC SSD in it (can't remember the exact model) that has been working great, even with large files. Sounds like the firmware for the SSD is simply not tuned well for long-running sequential writes on large files, which would explain the good read performance but poor (almost non-existant) sequential write performance. For what it's worth, a 7 pass DOD 5220-22.M wipe on the drive took about an hour and a half, including a verify pass.

Also, if you use oscdimg to create a UDF ISO with the -m -o -h options, it seems to work if you use the ISO in a virtual machine (at least Hyper-V and Virtual PC both work with >4GB WIMs in an ISO in my testing).