cluberti

I usually go for B, just in case - the data will be fine, and assuming you formatted them in Windows XP they're already likely NTFS 3.1 volumes, so nothing should need to be done once Win7 is installed other than plugging the drives back in and checking that you can get to your files (you may need to tweak permissions if you had anything esoteric configured under XP).

The FileInstall function is documented here. It's worth a read - if you've managed to create an entire autoit script, you should be able to follow that too .

If you need to change a retail or OEM product key to a MAK or KMS key, you should be using slmgr to uninstall the old key, remove traces of it from the registry, then install the new MAK or KMS key. If you use the Computer Management UI, yes, this can happen. slmgr /dlv - this helps you find the activation ID for the current activation; run this with the old retail or OEM key installed slmgr /upk <activation ID> - this removes the current product key by removing the activation ID slmgr /cpky - this removes the product key from the registry slmgr /ipk <product key> - this adds the new product key slmgr /dlv - this will show you the new activation ID for the newly installed product key slmgr /ato <activation ID> - this will activate the new product key Once you've done that and rebooted, you should no longer be told it's an invalid key. If you're still getting "invalid product key", check to make sure it's not a KMS key and your machine can't contact the KMS server, or that it's not a MAK key that has no remaining activations (either of these scenarios can cause "invalid product key" warnings for MAK or KMS keys, especially KMS server activations).

Under Vista/7, the scheduled tasks run as a service in session 0, which you by default cannot see. The only way to get a scheduled task that calls a cmd prompt to be visible is to make sure it is set to "only run when a user is logged on", and that user scheduled to run the task must actually be logged on when the task runs. By default, processes running in session 0 (where services, the default desktop, etc) are running cannot put any display information into session 1+ (where users actually log on and view their desktops) for security reasons. This is a change from previous versions of Windows, where session 0 was shared between services/default desktop and the console user, who also logged into session 0. In Vista+, all interactive logons are actually session 1 or higher, just like a terminal server session.

This one could have gone a few places, but I moved it to networks and the Internet simply because none of the locations I can put this makes sense, and we're talking about a file over the internet. It's a stretch, but so would the XP forum or the Software Hangout. Hopefully this will get some action here.

There really isn't a huge need for a better FS, honestly. NTFS already does all of the things the actual filesystem needs to do, although improvements to things that sit on top of it like Windows Search are always welcome.

The filesystem itself is the same (3.1) for XP/2003, Vista/2008, and Win7/2008R2, but the ntfs.sys driver itself and the kernel's I/O management have added changes and tweaks for things like better SSD support, Transactional Filesystem operations, self-healing, debugging extensions, etc. You can actually see the NTFS version of a volume using fsutil: fsutil fsinfo ntfsinfo <drive letter>: For example, on my Win7 box: fsutil fsinfo ntfsinfo C: NTFS Volume Serial Number : 0xf6accbccaccb8599 Version : 3.1 Number Sectors : 0x000000003a3557ff Total Clusters : 0x000000000746aaff Free Clusters : 0x000000000616a236 Total Reserved : 0x00000000000007e0 Bytes Per Sector : 512 Bytes Per Cluster : 4096 Bytes Per FileRecord Segment : 1024 Clusters Per FileRecord Segment : 0 Mft Valid Data Length : 0x0000000007bc0000 Mft Start Lcn : 0x00000000000c0000 Mft2 Start Lcn : 0x0000000000000002 Mft Zone Start : 0x0000000003b04920 Mft Zone End : 0x0000000003b11140 RM Identifier: CEF11C5E-77FE-11DE-85EE-B7DA22FC12FB

Home use programs, yes. That's about it though.

Could you post your sysprep.inf file (X out the PK, of course), as well as attach the lastsession.ini from nLite if it was used to create this SP3 CD?

Consider something like WSUS then - WSUS 3.0 SP2 on a Windows Server will act as a WU point and download/cache updates, you approve the updates to be downloaded and made available to clients from WSUS based on the options you configure, and then you point your machines at the WSUS server instead of WU for updates.WUD is something more useful to folks who need to cache updates for slipstreaming into images, or personal machine use, etc - when you start getting into having multiple machines and desiring control over updates, caching, etc, you need to look for something designed more for that (like WSUS is).

Not unless dllcache has logic to do it, no, they do not automatically get copied. I've seen this before with a few IE hotfixes when I used to use hfslip, and it was always a disk problem. Sorry I didn't see it sooner, I could have suggested it .

You can't disable DEP for drivers, but you can for .EXEs if your system is set to opt-in. Disabling DEP means the system is no longer checking for executable code coming from pages not marked PAGE_EXECUTE, meaning buffer overruns and other types of pointer/load attacks are much easier to exploit (similar to the vulnerabilities patched by Microsoft in the MS10-002 patch, for a recent example). If disabling DEP fixes a driver, you have likely no recourse but to disable DEP or use a different device driver that isn't poorly written.

Things like MDT and SCCM allow you to create structures and scripts (task sequences) that allow for driver control, app control, variables, etc before, during and after install, and can be driven and controlled by data in a SQL database even. SCCM does more in that it's more than just deployment, it's PC lifecycle management from deployment to replacement, but it's also not free - MDT 2010 is free, but of course is just the OS deployment portion of SCCM (and it's not 100% of it, either). It's true you could replicate this on your own, but it would take a lot of time and effort, and these are Microsoft-supported as well using the native tools to work with their native images. Ricktendo's videos are good, and I've got some walkthroughs on my blog about MDT as well.

You could probably re-use your current methodology without any problems, but using WDS and the WAIK (perhaps coupled with MDT 2010 or SCCM 2007, depending on size and scope of your environment) would be just as easy, and probably more flexible.

To view these, are you running the ODBC admin application directly from the .exe in the \Windows\SysWOW64 folder? I believe it's odbcad32.exe.

Also note that using something like vLite on an OS image that you would ostensibly want vendor support for invalidates the EULA for the install, and thus Microsoft won't support it (they won't support nLite'd OSes, and they won't support vLite'd OSes either). This is, in general, a *bad idea* for a workplace scenario anyway (above and beyond the usage of vLite in a non-personal scenario, which violates the EULA for vLite as well). If you're making images for a workplace environment, consider using officially sanctioned tools like Microsoft Deployment Toolkit or System Center Configuration Manager (depending on the size and scale of the environment, of course). There are non-Microsoft tools that assist with this as well, although MDT 2010+WDS is free (short of the Windows Server OS license to run it) and a pretty darned good solution for deployment for smaller environments.

The error is "ERROR_INVALID_FUNCTION", so either the folder where you're trying to mount the WIM file has a problem, or the image itself is corrupt in some way. You might want to get a process monitor log while you're recreating the error, and then see if there are any obvious errors in the procmon log that would indicate the failure.

It's been recommended to use .cmd files since Windows NT - only use a .bat file if you actually *need* the 16bit command.com interpreter. I cannot think of many scenarios nowadays where a script would need access to the 16bit interpreter (what you have posted here certainly does not), as the 32bit cmd.exe does pretty much everything you should need - since 1993!

Poor little fellow , I care for your unfortunate situation, in which you do not get the answers you want, what a pity. [italian] L'erba voglio cresce soltanto nel giardino del Re [/italian] (the above translates roughly to "The grass "want" only grows in the King's garden") Yes, you can write them allright, if you LEARN how to. jaclaz jaclaz, I do not know what's going on with you and babuleto, but please either try to help or don't post a response on MSFN to posts like this. We don't want to see these types of responses on MSFN from anyone, and this isn't the first time this has happened with this user. I'm assuming there's a reason, but "take it outside" as it were. And to user babuleto, it seems all of your posts here on MSFN are in the vein of "how do I do <insert something here> THANKS BYE". I'm going to say that the assistance you got from MrJinje is correct, but you do actually need to try and find some of this on your own. On to my own rant: You're asking here and many other boards the same sorts of things (as per jaclaz's link above), but I don't see you helping others here on MSFN at all. If all you're going to use MSFN for is to stop by, ask a few questions (that could have been answered by an internet search, reading product documentation, or using Technet and/or MSDN), and then leave until you have some other issue you need us to provide documentation for you to resolve, please consider now a good time to start to learn how to use Google and MSDN/Technet for your questions. MSFN is a forum/community where we all try to help each other. We are NOT your helpdesk, and if all you're going to do is take from MSFN (you haven't posted back anything of value that I can find to actually help someone else since you joined in early 2009), please take from somewhere else. Thank you. [Closed].

First, welcome to the forums . Second, are you sure it's a 0x7D bugcheck? If so, that would indicate that Windows doesn't find enough memory installed in the system to boot, and given installing chipset drivers seem to cause the problem I'm wondering about those drivers and your motherboard's actual chipset, and whether they're compatible or not.

You've been here for less than 30 days and show blatant disregard for our rules. I don't know how it is there in the Netherlands, but users who want to participate in our forums are required to actually follow the rules - all of them, like them or not.[banned].

Yes, it's similar to XP's superfetch, but rather than just align load orders on disk, it does a lazy preload of binaries that get used the most on the box as you use it, and it adjusts itself as necessary as you go.

In progress. See the link just below yours in this section for details: http://www.msfn.org/board/index.php?showtopic=141487

I'm not sure there would ever be a need for a paging file that large, unless you have more than 4GB of RAM and are worried about having the paging file size available for crash dump recovery.

Might want to get a process hang dump of the wmplayer.exe process when it's in this state (no UI, but hasn't closed out) to see what it's doing.