cluberti

I would perhaps enable verbose logging first and try ANY MSI install again, and see if the log file gets created in %temp%. If not, you'll know it never got far enough to even start the service and create the log - but if so, it might give some info as to what's happening. The error does state that there's a problem with the service, but it doesn't say what (nor is it anything but vague), so there may actually be a problem with the service that a log will display. I wouldn't recommend reinstalling SP2 on the server unless this machine was recently built and isn't in production (of course at that point, I'd recommend reinstalling the whole OS - it'd be quicker).

Enable Windows Installer verbose logging (the article is for XP, but any XP/2003 system with MSI 3.1 or newer can do this) and check the resulting log file in %temp% for actual verbose failure information. It is worth noting that error 1719 means "Windows Installer service could not be accessed. Contact your support personnel to verify that it is properly registered and enabled.", so making sure the installer service is installed and registered properly is a good idea, and upgrading to 4.5 isn't a bad idea either if you haven't done so already.

Right where the KB article says you'll find it:

Yes, $1 represents the system volume (the one Windows is installed to), which is of course usually C: on a clean install unless you've changed the drive letter with autounattend. That means that during installation (near the end, after the WIM has been laid down onto the disk) the contents of $OEM$\$1 will be copied to the system volume as their folder names - so for example, you would see this folder post-install as %systemdrive%\APPSX86.

It is a neat trick, but you weren't the first to find it. However, credit where credit is due I've edited my post to point to this thread to make it more discoverable.

What kind of sharks? Not all will attack and eat an unharmed man in the ocean . This is a good question, and I've used it along with a few others to "watch" someone's cognitive skills in motion.

Magic .

If an MSI installer is trying to start when you log on, it's very likely that some installed MSI app is trying to repair itself (for whatever reason). It would be useful to get a verbose log of the installer and see what happens, rather than trying to band-aid it.

It sounds more like the powers that be want functionality and behavior that come with using Windows Terminal Services and RemoteApp (or Citrix App Publishing), where the app is the shell - closing the app logs out the user. However, to keep people from running things other than the app (if that is indeed the goal), you'll probably have to use software restriction policies to keep other .exe files from launching for these users. It's not as difficult as it sounds, but it certainly isn't easy either as you must be VERY careful what you restrict and how.

I see you've already talked to Darrell. It seems like in the Unattend you can (in the Microsoft-Windows-Setup > DiskConfiguration > Disk > ModifyPartitions > ModifyPartition > Letter hierarchy) set the system partition, usually disk 0, order 1, partition 1, and then set the letter for the Windows volume (assuming 1 100MB partition and a second partition using the rest of disk 0) on disk 0, order 2, partition 2 using the Letter modification (assuming you'd use <Letter>L</Letter>). BTW, the installation is not set in the installation anywhere, it's just that after the image is applied (and the system rebooted), the first available letter (starting with C) is assigned as the system is specialized. Assuming you're going to try an autounattend.xml, look into the DiskConfiguration step of the Microsoft-Windows-Setup hierarchy, in the WindowsPE pass. It is indeed in the help documentation.

It's XP Pro, VLK, Portuguese.Anyway, back to the OP - if the installation is prompting for a key, and DefaultHide is set as the mode of unattend, that means the key is NOT a VLK key. If it's asking for a key, and there's one in the unattend, then this is why it's asking - you probably have an OEM or retail key, and for some odd reason you've created an unattend with VLK media.

If it really is an .exe file, it would make sense that something has damaged or removed the exefile handler in the registry. I won't take credit for this (it originally was found on teh intarwebz years ago, and it's been maintained through at least WinXP by a few people), but save the code below in a text file, rename it as a .reg file, and execute it to import the data into your registry. I keep this in my recovery toolkit, because lots of malware tend to break the exefile handler in an attempt to keep anti-malware apps from being able to run. Primitive, yes, but effective for low-hanging fruit. Thankfully a simple reg import will fix it: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.exe] @="exefile" "Content Type"="application/x-msdownload" [HKEY_CLASSES_ROOT\.exe\PersistentHandler] @="{098f2470-bae0-11cd-b579-08002b30bfeb}" [HKEY_CLASSES_ROOT\exefile] @="Application" "EditFlags"=hex:38,07,00,00 "TileInfo"="prop:FileDescription;Company;FileVersion" "InfoTip"="prop:FileDescription;Company;FileVersion;Create;Size" [HKEY_CLASSES_ROOT\exefile\DefaultIcon] @="%1" [HKEY_CLASSES_ROOT\exefile\shell] [HKEY_CLASSES_ROOT\exefile\shell\open] "EditFlags"=hex:00,00,00,00 [HKEY_CLASSES_ROOT\exefile\shell\open\command] @="\"%1\" %*" [HKEY_CLASSES_ROOT\exefile\shell\runas] [HKEY_CLASSES_ROOT\exefile\shell\runas\command] @="\"%1\" %*" [HKEY_CLASSES_ROOT\exefile\shellex] [HKEY_CLASSES_ROOT\exefile\shellex\DropHandler] @="{86C86720-42A0-1069-A2E8-08002B30309D}" [HKEY_CLASSES_ROOT\exefile\shellex\PropertySheetHandlers] [HKEY_CLASSES_ROOT\exefile\shellex\PropertySheetHandlers\PEAnalyser] @="{09A63660-16F9-11d0-B1DF-004F56001CA7}" [HKEY_CLASSES_ROOT\exefile\shellex\PropertySheetHandlers\PifProps] @="{86F19A00-42A0-1069-A2E9-08002B30309D}" [HKEY_CLASSES_ROOT\exefile\shellex\PropertySheetHandlers\ShimLayer Property Page] @="{513D916F-2A8E-4F51-AEAB-0CBC76FB1AF8}"

It is, but it puts all of your NTLM data in clear text out on the wire - not that the NTLM hashing in NT4 is great, but it's something. Cool that someone figured it out, not cool what it takes to make it happen .

Windows 7 is the same kernel and driver model, so choose Windows 7.

I don't need a pic, just make sure it has a product key on it. Assuming so, enter that key into the activation wizard (when prompted about activation, follow the wizard) and hopefully it'll work.

Stop 0xF4 is critical object termination (lsass.exe, csrss.exe, or winlogon.exe - if you had the .dmp from that crash we could say for sure which it was), and a Stop 0x135 isn't a Microsoft Windows bugcheck, so that would mean some non-Microsoft driver called KeBugCheck to crash the box with a custom code.

It's being investigated - there was another bug we found yesterday, and although not related, we're on top of these. Thanks for bringing it up.

Drive letters are determined at install time if we're talking about installing Windows to a drive other than C:, and even if you install Windows on L: (which would have to be the 10th volume that Windows can see and assign a letter to during the install), you're still going to have drives C: - K: as well (which may or may not be something you want to do, it's not clear from your post). You can actually change the drive letter of the Windows volume post-install (as Windows generally uses the literal object path internally when referring to a volume), but this may break existing registry data for apps that do use the drive letter (shell folders, etc). I've not ever tried changing it, but it should be easy to test in a VM if you want to test it before doing it with a real install. However, if you want Windows to install to the "L" drive during install, you'll have to make sure you have 10 volumes, online, and formatted, and you'll have to install to the 10th volume (aka, "L"). I'm guessing this is probably for aesthetics rather than something functional, but I'm not sure how useful it is (and it won't necessarily be easy to do either).

Highly suspect that Home Basic was on a Sony laptop sold in the US - it would have been Windows 7 Starter, with an upgrade option to Home Premium, Pro, or Ultimate. As has been stated, Windows 7 Home Basic is not actually sold in the US at retail or from an OEM, only in emerging markets. If you purchased this netbook from a US retailer (Sony or an actual Authorized Reseller), then you need to consider the notion that it is at least very likely that the copy of Windows 7 Home Basic installed on that netbook is *not* genuine, and/or was not installed by the OEM. A Windows 7 installation on an OEM system would have an SLIC license, in which activation is tied to the BIOS. Unless the BIOS was upgraded (and it would have to be a pretty major upgrade) or the motherboard itself was replaced, Windows on an SLIC system should not be displaying any activation errors. Again, since it's tied to the BIOS, and the BIOS did not change as you said, there's no way for this to fail and cause activation errors - however, the fact that it's been about a month since the purchase makes it more likely (since the grace period is 30 days from install to activation) that the installation is invalid and the reseller either inadvertently or knowingly sold an unlicensed copy of Windows 7. At this point I would strongly suggest looking for the COA sticker that has a product key on it affixed to the bottom of the netbook (legally, that's where it should be if sold by an authorized OEM), and make sure that the product key is for Windows 7 Home Basic (given that this is not available from a US retailer or OEM I'm not sure how this is possible, but look anyway). I think what you're likely to find is that the OS install is not geniune (pirated), was not activated on install (again, Home Basic on a US machine is technically impossible), and is in need of replacement from the reseller or the actual OEM (that netbook *did* come with an OS at one point, and the COA should show you what version of Windows is supposed to be on that netbook). If you find it to be non-geniune (and I'm guessing you will), it's also worth contacting Microsoft *and* Sony and reporting this authorized reseller as well, so this does not happen to someone else.

Not technically, no. But you can set a time for which the user cannot change the password again after doing a required password change, so that if a user changes their password (enforced, say, once a month for example) they cannot change it again for <x> days (the Minimum password age policy, I beleive). Also, you could lock down the UI as well: http://support.microsoft.com/kb/324744

You could do this with an XPMode VM, but you aren't going to get access to (or join up with) anything on that NT4 domain.

Yeah, something quite obvious too: http://support.microsoft.com/kb/940268 http://technet.micro...706(WS.10).aspx

And if recreating a baseline image exactly the same as the previous (to avoid multiple generalize passes on an image), consider MDT or SCCM for image build and deployment, or something similar.

No, it does not. It has scratch space for writing "to disk", but it's not intended as a paging file. Windows PE runs from a RAMdisk (unless you configure it otherwise), and is meant for deployment and recovery only, not a whole OS - hence, no paging file.

http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/99816a8b-bad4-4d44-8fea-2c77e2e481bd