cluberti

Well, I used it, it worked for what I used it for. However, that's why you get a trial version and test.

I've seen the latest version of Ghost as a trial (didn't choose it over SCCM and MDT, ultimately), but it did work just fine.

// Looking at the UI thread, as this would be responsible for completing the page render - we can see it is indeed waiting. // Note the kernel32!WaitForMultipleObjectsEx call, the first parameter is the number of objects, the second is the handle list, // and the user32!RealMsgWaitForMultipleObjectsEx has as it's 3rd parameter the amount of time to wait for these to be handled: 0:000> kb ChildEBP RetAddr Args to Child 0012e68c 7c827cfb 77e6202c 00000002 0012e6dc ntdll!KiFastSystemCallRet 0012e690 77e6202c 00000002 0012e6dc 00000001 ntdll!ZwWaitForMultipleObjects+0xc 0012e738 7739bbd1 00000002 0012e760 00000000 kernel32!WaitForMultipleObjectsEx+0x11a 0012e794 00fa6029 00000001 0012e7c8 ffffffff user32!RealMsgWaitForMultipleObjectsEx+0x141 0012e7b4 00fa632d 000004ff ffffffff 00000000 ieui!CoreSC::Wait+0x49 0012e7dc 00fa60d8 000004ff 00000000 4383992d ieui!CoreSC::WaitMessage+0x54 0012e7e8 4383992d 00150758 0014e080 00000000 ieui!WaitMessageEx+0x33 0012e818 4382abac 001517a8 0012e848 4382bc1b ieframe!CBrowserFrame::FrameMessagePump+0x199 0012e824 4382bc1b 00000000 00000000 00150758 ieframe!BrowserThreadProc+0x3f 0012e848 4382bb69 10cc0006 00150758 00000000 ieframe!BrowserNewThreadProc+0x7b 0012f8b8 4382ba19 00150758 77db149e 00000000 ieframe!SHOpenFolderWindow+0x188 0012fae8 0040147c 00148840 00000001 00410070 ieframe!IEWinMain+0x2d9 0012ff2c 00401317 00400000 00000000 00020700 iexplore!wWinMain+0x2c1 0012ffc0 77e6f23b 00000000 00000000 7ffd6000 iexplore!__wmainCRTStartup+0x150 0012fff0 00000000 00402e45 00000000 78746341 kernel32!BaseProcessStart+0x23 // Dump the list to see what we're waiting on, looks like 2 handles, as the wait call indicated: 0:000> dl 0x0012e760 0012e760 00000128 00000044 00fa62bd 290c0d66 // Check the handles: 0:000> !handle 00000128 Handle 00000128 Type Event 0:000> !handle 00000044 Handle 00000044 Type Event Knowing that a wait of 0xffffffff means indefinitely, the only true way to find out what these are would be to try and capture the hang before it hangs to see who's setting the events that aren't firing, but knowing it's entirely random that will likely be very difficult. You could find out more about these handles with a full memory dump of the entire machine when the problem occurs, but the problem has already happened before the hang, as thread 4 in this dump was supposed to contain the handler for the events but at this point whatever was there is long gone.

bumping due to double post. Hopefully someone else will see this and respond.

Do not double post.

OCSetup from the command line will do this, and I believe the component is called "InboxGames". Found this via Google, btw.

The score is based on far more than just how fast the drives do sequential reads and writes. See this thread for more info and how to check and see how your drives score.

When you say "security blob" are you saying that you don't think that disabling these things will increase security or are you saying that you don't know what the "RPC" tweak does? This tweak: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc] "DCOM Protocols"=hex(7):6e,00,63,00,61,00,63,00,6e,00,5f,00,73,00,70,00,78,00,\ 00,00,6e,00,63,00,61,00,63,00,6e,00,5f,00,6e,00,62,00,5f,00,6e,00,62,00,00,\ 00,6e,00,63,00,61,00,63,00,6e,00,5f,00,6e,00,62,00,5f,00,69,00,70,00,78,00,\ 00,00,00,00 ~Disables "ncnacn_ip_tcp" DCOM Protocol under RPC Services. I read an article from 2002 that said that disabling this functionality prevented Blackhats from sending packets to this service and it closes this port (forget most details honestly). Been doing this since 2002 on XP and it's served me quite well with penetration testing and such. If you disable that on Vista you'll actually get an RPC error on boot if your machine is set to get an IP from DHCP (DHCP relies on this being enabled), so I wouldn't do it. The security hole supposedly doesn't exist on Vista (and thus Win7) anyway, although I don't know how you'd verify it without trying to hack it. For what it's worth, however, if you have DCOM disabled COM won't be listening for remote connections anyway, so it's largely a moot point.

Kaspersky has a version of their antivirus product specifically built for Win7, and other product versions are not slated to have updates for Win7 until RTM, so this is not surprising.

You can use DSIM from the Windows 7 AIK to add and remove drivers to an offline image. Download the Windows 7 AIK and read the help files about DSIM, it's in there. Or, you can *try* to use vLite, although vLite and Windows 7 don't get along 100% of the time so caveat emptor if you go that route.

I'm not sure about the security blob, but the other two still apply to COM on Vista and Windows 7, yes. Note you can modify these in the GUI in dcomcnfg as well.

This problem seems to exist with USB keys as well - I have a 4GB key and a 64GB key, and I cannot get the installation of Vista OR Windows 7 to work from the 64GB key, unless it has only a 4GB partition (and nothing else). the 4GB key obviously works fine, and my previous 8GB key had the same problems. I believe there's some sort of issue with images larger than 4.7GB, so I'll file the bug. We'll see if this is expected or not.

Yes. Visit the Solution Accelerator page, then click the link under the Microsoft Deployment Toolkit 2010 section entitled "Click here to be instantly joined to the beta program", then click the "Microsoft Deployment Toolkit 2010" link to see the project page and downloads. Note that it requires you to have a Windows Live ID registered with connect for this to work, but it just worked for me, so it's still there.

That really is interesting. For what it's worth, this isn't normally how I install Vista or Win7 anyway - I use MDT and WDS to create the images and deploy them, which allows scripting, app install, driver injection, and some reporting as well. It's worth considering if you're moving to all Vista images (you can do it with XP and 2003 as well, but since most people at this point have a system they've used for many years it probably doesn't make sense to rip it out and replace it with MDT). Note that the original images you're using (Vista or Win7) are images to begin with, so the fact that they deploy to your hardware but yours don't again seem to indicate either a problem with your capture or a problem specific to your hardware. Remember, the Vista and Win7 WIM files are *already* images that were sysprep'ed on the media, so.... And honestly, I would still suggest not imaging if at all possible anyway, and using tools like Microsoft Deployment Toolkit, System Center Config Manager, and a decent Server 2008 box running Hyper-V (for testing and any imaging you really do need to do) for such a large deployment. You can do basically the same thing with smaller images and scripting certain things via MDT and/or SCCM, and it would be more "hardware neutral".

Yes, this is about what I'm getting on my 3.8 box. There was a "refactoring" of the scoring for the RC (don't know if there'll be another before RTM) due to the i7, I believe, so it makes sense this is lower than it was in Vista or build 7000. I get the same scores with a similar Thinkpad, so I believe this to be expected. Just remember the score is just a score, it's not going to affect your ability to use the OS (and anything over a 3 is technically considered "good" hardware for Win7 - netbooks running the Atom 1.6 generally score around 2.1 or 2.2, and they run Win7 quite well. My 7.1 Core2Duo box gets the following scores, for reference: > Running: CPU Assessment '-compression' > Run Time 00:00:10.28 > CPU LZW Compression 254.64 MB/s > Total Run Time 00:00:12.95 > The System processor power policy was restored > Running: CPU Assessment '-encryption' > Run Time 00:00:03.21 > CPU AES256 Encryption 156.27 MB/s > Total Run Time 00:00:05.15 > The System processor power policy was restored There is a delta there, and it's pretty big - anything under 100Mb/s in the compression test will not score above a 4.0, although I don't know about the encryption tests. Hopefully the documentation whitepapers on Win7 at RTM will explain the scoring in more detail than the beta documentation did, but your numbers do seem pretty low. Note that the scoring and WinSat in general isn't being backported to Vista, for what it's worth, so Vista scores will not get parity with Win7 scores when it RTMs either, although I'd argue the Win7 scores are much more accurate than the Vista scores.

This is why you test your ISO in a VM before you destroy a perfectly good install with one that might not work. nLite removes components that the installer may need, depending on what you're installing on, what hardware drivers get loaded during install for your hardware, etc. Considering nLite is actually *stripping* the components out of Windows, this can cause problems. Expecting it to always work no matter what you remove, slipstream, or add is silly. Always use a VM before you run the install on a machine you actually need. BS - Error code 11 means the WIM image the program is trying to access either isn't the correct bitness (using an x86 wimgapi to open an x64 WIM or the converse), or the WIM file itself is damaged in some way. I've had this error many times before, and it is ALWAYS the image file's problem that a redownload of the ISO from MSDN cures. And honestly, with only one post that shows you as unable to search and nothing but a complainer, we won't miss you. Goodbye. Then perhaps STRIPPING components out of Windows directly using nLite or vLite is also something you should be considering above your experience level. This is not Windows 101 here, for goodness' sakes. And the developer's time and energy isn't? You got a free product even though it took someone a good long time to make a product that works just fine for most of us, and yet you're complaining about how it doesn't work and how YOUR time is worth something? The argument that you got what you paid for is perfectly valid here, and if you don't understand what the product does or how, or don't investigate the risks involved, and then complain about something bad happening when you've been warned it's possible, then don't use the product. Stop whining like a petulant child.And since the rest of your post is also just a rant about things unrelated to vlite or nlite, I'm going to grant your wish. Thread closed.

http://www.msfn.org/board/index.php?showto...hl=default+user

Visio requires ODBC to create a database for it to work properly. This database is a JET database format. Removal of the JET Database Engine component will cause this to fail, because the dependancy component Visio needs is no longer in the OS. Not to mention you already got the same basic answer from your thread here. Unfortunately, they were right, and so are we. Removal of the JET Database Engine component means any application that uses a JET database dependancy to function (like Access or Visio) aren't going to install or work properly, period.

Note that removing a component with vLite or nLite is not the same as removal from within Windows - with xLite, the component is literally *removed* from the install image. You can't add components back once you've removed them - you'll have to re-vLite your original Full installation and add the components back that you want to keep, then make a new image and install from it. This is why you'll always find people asking this question here, and the rest of us always telling you to be sure of what you're removing before you install, *just in case* you might want that feature in the future because they can't just be hacked back in (especially in Vista and Win7).

Sysprep "generalizes" the OS back to (as much as possible) as pristine and unused a state as is possible. This process is actually documented pretty well on Technet, part1 and part2, so I suggest reading these a bit if you're confused.

Perhaps I'm missing something, but the rearm is specifically designed to extend the evaluation period, so you aren't "circumventing" anything by using it. As per the KB article itself: That wording is specific: "how to extend, or re-arm, the Windows Server 2008 evaluation period". It is designed explicitly to allow just this. Again, perhaps I'm not understanding your position, but Microsoft clearly spells out that this is an OK use of the rearm portion of the slmgr script. It doesn't allow you to get around activating your product, it just allows you to postpone it (again, up to 3 times) for a total of 240 days from the point of install. In a lot of environments, this isn't just a nicety, it may be necessary to evaluate the product before deciding to go with the platform - thus having the 240 days means you don't have to reinstall and reconfigure to continue testing and evaluating the product.

You could also use something like MDT 2008 to provide the deployment choices to the users, which allows you to put credentials into the configuration files on the server so the users never get prompted. Assuming you aren't using the credentials to provide a specific image or set of images to display to the users (which is all this is really for), then this might be the easiest way to go. It can be easily automated using config files too, so they only see the choices they need (it builds the unattend.xml file from these choices on the fly which then get applied to the image deployment).

You can use vLite, use the instructions found in neo's blog post, or you can use cdimage to do it manually as posted on MSFN earlier.

Any particular reason you're not using an x64 version of Server 2008? According to Dell, the Vostro 220s came with a choice of a Pentium Dual-Core E2200, E5200, or E5300, or a Core2Duo E7400, E8500, or E8600. All of those CPUs should have 64bit support, according to Intel.

Agreed - against the blue background, it's almost completely illegible.