cluberti

Because IE 5.5 hasn't been supported for years (support ended for IE5.5 on it's last supported platform, W2K SP3, on December 31, 2003). Microsoft only comments on supported configurations. I can't comment on the rest, although it's quite possible Win9x systems are vulnerable as the font engine didn't change much from Win95 - WinXP, and finally got an overhaul in Vista.

A couple of things regarding this code: 1. adding this script to the head to resize/center the window is much faster than the existing method: <script language="javascript"> var startWindowWidth = 1024; var startWindowHeight = 768; var startWindowLeft = 1; var startWindowTop = 1; window.moveTo(startWindowLeft, startWindowTop); window.resizeTo(startWindowWidth, startWindowHeight); </script> 2. The logic for checking window size doesn't work in some scenarios and you get offscreen windows if you use setres to resize a window from 800x600 to something larger (in my case, 1024x768) and have BORDER = none (which I do). Specifically, the map network drive and diskpart windows are almost completely off-screen - I've changed the logic as follows, since I know my screen is going to be 1024x768 for sure, I don't need to waste the time doing a lookup and can hard-code these: '**************************************************************************** 'Network Drive mapper '**************************************************************************** ...<snip>... objFile1.WriteLine "Sub Window_Onload" objFile1.WriteLine " startWindowLeft = 312" objFile1.WriteLine " startWindowTop = 299" objFile1.WriteLine "" objFile1.WriteLine " window.moveTo startWindowLeft, startWindowTop" objFile1.WriteLine " window.resizeTo 400, 170" objFile1.WriteLine "End Sub" '**************************************************************************** 'Diskpart '**************************************************************************** ...<snip>... ObjFile.WriteLine "Sub Window_Onload" objFile.WriteLine "On Error Resume next" objFile.WriteLine "objFso.DeleteFile(TempTXT1)" objFile.WriteLine "On Error Goto 0" objFile.WriteLine " startWindowLeft = 312" objFile.WriteLine " startWindowTop = 194" objFile.WriteLine "" objFile.WriteLine " window.moveTo startWindowLeft, startWindowTop" objFile.WriteLine " window.resizeTo 400, 380" ObjFile.WriteLine "custom.style.visibility = "&chr(34) & "hidden"&chr(34) & "" ObjFile.WriteLine "End Sub"

I don't think you can slipstream KB947821 properly, ever - it requires access to registry locations and files that aren't technically "ready" until the machine is actually installed from the WIM. If vLite is integrating it properly, that would seem impossible and it's likely just erroring out silently. Also, this tool is useless unless run against a running system, which is another reason not to integrate it.

I know the thread was resurrected, but the error code in question maps to "ERROR_FILE_CORRUPT". Might be worth exporting each index in the WIM to it's own .WIM file and slipstream/testing each - once you're sure they all work, export them all back into a combined WIM file. It'll reduce the size of the resulting WIM, and you'll be certain each version works properly (and have a working copy of it in a separate WIM just in case).

So the fans don't connect to the motherboard at all in any way? Usually the sensors are in the motherboard, not the power supply, so if they're not attached that could be (or perhaps only some of the fan mounts are sensored, etc).

It is getting it's unattend answer file from somewhere, or at least it thinks it is. When you get the error, press Shift+F10 and get a cmd prompt. You should be able to browse for the log files from the installation - usually if there's an unattended installation going on, you should find an .xml file on the root of the DVD or in the \Windows\Panther directory - if not, and you truly didn't create an unattended answer file for this install, I'd have to agree with Mr Jinje that something's wrong with the source and you would probably be best served starting over and taking it in steps to see if you can get all the way back through without breakage. I know it will take more time and a lot of trial and error booting in a VM after you strip each component, but it might be worth it in the end.

Note that the .exe in question was provided to AVG for analysis by a fellow moderator, and their response was that this was a false positive, for what it's worth, and detection of this would be fixed in the next signature update. I have updated the thread title to reflect this, and suggest anyone with antivirus software detecting this as a virus submit it to that A/V provider as well for deeper analysis.

Remove it completely, no - but removing the binary so it cannot execute, yes - using the "/Disable-Feature /FeatureName:InternetExplorer-Optional-<arch>", either /online or against a WIM /image: will work. Replace <arch> with the architecture of your Windows image - amd64 for 64bit, x86 for 32bit, and ia64 for itanic.

Understood - but it is always better to have logon and/or logoff auditing enabled in that case on the DC and the member servers going forward, and it's also a good idea to archive those logs regularly if they'll be needed for any type of forensics. Given the log entry above, it would indicate more a share access than a logon request.

The onAction property calls a VB procedure or a COM add-in that runs when a user clicks on or changes the value of a command bar control. The procedure should be one that you've written in your code, or the COM add-in can be any valid COM add-in installed and enabled in the Office application at the time. So, there's no "master list", because you're either writing the procedure that is called, or you can look through the list of COM add-ins installed on a machine and use one of those for your onAction property event.

You have to remember the memory manager bias though - the more paging file you give an XP system, the *more it will be used*. The OS will try it's darndest to make sure that running applications are in RAM, and minimized applications or background tasks can (and will) be paged to make sure there's enough "free ram" on a just-in-case basis (it's more complicated than that, but for this discussion the layman's description here should be fine). This can be easily tested by setting a very small paging file and running a workload that is smaller in memory footprint than the installed amount of RAM - then, increase the paging file and run the same workload again. You will notice that on the first run, the system (minus what can be needed in a pinch for kernel paged pool memory) will keep everything in RAM and run just fine, but if given the paging space it will use it (heavily, at times) even if there's no risk of "running out of RAM". The bias is better on Vista and much better on Win7 machines, partially because XP was built on a kernel that was designed and tweaked during the NT era and thus behaves in an archaic manner, and partially because XP does little caching to try and improve performance, whereas Vista and especially Win7 try to take an active role in making sure that what needs to be in memory is, and what doesn't won't be - unless there's RAM to spare, in which case it'll leave things alone and simply keep pages on the ready list rather than actually swapping them out.

That's true, if they're time-bombed they may well have a redist agreement in place (it's not all that uncommon). If they're redist'ing full OSes, however, I'd be pretty suspicious.

Yes, 2 sessions - however, there's no logging into session 0 on 2008 or 2008 R2 anymore, so you only get two. Even local logins aren't session 0 anymore, for what it's worth, that usually catches admins by surprise when they move from 2003 to 2008 / R2.

Depends on the licensing agreement the vendor has with Microsoft - redist of Virtual PC is probably OK no matter what, but redist of an XP VHD would definitely require some sort of licensing agreement between the vendor and Microsoft. It's worth bringing up to your TAM to have it looked into if you've got a premier agreement.

In general, the only posts we delete are spam, violations of the rules, etc. If a post doesn't meet either of these criteria, especially if there are responses in a thread, we don't delete it, ever. As to the request for deleting threads, I don't see any reason to do so. They don't really fall under the spam or violation of forum rules, and while they may not have a lot of technical merit (or none at all) I don't see any real reason to remove them either. They're part of MSFNs history, so I'm leaving them up for now.

I honestly don't remember if it was included in PE 2.x, but it could have been. I don't have one around to test at the moment, so my answer is going to be "I don't know". I do know for sure it isn't included in WinPE 3.x.

I think it might be useful to run hijackthis on this computer, and attach your log file to this thread. I'm moving it to the malware discussion alias for further assistance.

Been messing around a bit with 7.1, as 9.x is unstable as hell for my needs, and I decided to make a new pe.jpg to go in the pics folder to make it more Win7-like: You have to go into misc, edit htastyle.css, and add "color: #FFFAFA" in the #title section, otherwise the default black text for the title is too hard to read (it's the color code for "snow").

If you've got Win7, you could use disk2vhd to make an image of it, and then mount the VHD as a disk using disk management.

It also looks like they're getting their error code out of ntdddisk.h, and if so that means "SMART_INVALID_DRIVE". Another reason to believe it's corrupted.

You should indeed, yes, as \Windows\memory.dmp.

Fixed that for you. We've codified common sense about it now.

It's worth noting that you can enable some compression and some single instance when putting Microsoft OSes into an ISO by using the oscdimg tool that ships with the WAIK. For example, "oscdimg -u2 -m -o -h -b<path to etfsboot.com> -l<ISO label> <path to folder containing OS files to put on disc> <path to and name of .iso file>.iso" creates a UDF formatted ISO for Vista or Win7 installation media that is fairly compressed and single-instanced to reduce size.

It's also worth noting that going spelunking for historical data like this when there was no auditing or data gathering policy really configured on the DCs and workstations beforehand is generally an exercise in futility. If this is the case, you'd be better rectifying the situation by enabling the amount of logging and auditing your domain can handle and that someone (or some group) is comfortable monitoring and hoping to catch the next occurrence.

choice.exe does not exist by default in WinPE 3.0 - you would have had to have copied it into your .wim file offline to use it. Remember, choice.exe is from DOS, as is the command.com interpreter. You might want to consider vbscript or an HTA rather than a CMD in your WinPE environment, as getting information out of WMI on WinPE is much easier than using a batch: strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery( _ "SELECT * FROM Win32_CDROMDrive",,48) For Each objItem in colItems Wscript.Echo "CD Drive: " & objItem.Drive Next I know vbscript is more "code-like", even though it's just a scripting language, but it's tons more powerful, and can have HTA (HTml Application) front-ends for it too. Worth considering, if you're gonna do a lot of work inside WinPE.