joebalt's questions

I've been scratching my head about this one, and have googled around for answers, but didn't find anything interesting - I am sure it's probably a matter of my search terms at this point, but I hope someone out there knows why I am seeing this behavior.

I am looking to link an msi install to it's corresponding \Windows\Installer\msi_munged_file_name.msi. I use /l*vx logging to get the MSI install log, and I see an entry like this:

PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\Windows\Installer\1f219540.msi'.

And I watch as the file system does indeed get that file created. But, after MSI finishes, the file gets renamed. o_O

I've gone through 2 iterations of this, and both times the file has been renamed to what it was before +3 hex, I think. So, in this case I wind up with a file named:

C:\Windows\Installer\1f219543.msi

I am curious as to why the rename happens, and if the algorithm is to indeed +0x3 the last character in the file name, or if this is just coincidence on my 2 runs so far.

I've used Orca.exe to verify that the file that results in C:\Windows\Installer is indeed my msi.

This is for research I am doing on Windows Installer, and I am trying to better understand the MSI/Windows Installer platform.

Thanks in advance!

Is there such a utility or capability an MSI? Perhaps msiexec?

rpm -ql provides the list of all the files installed by a given package. I'd like to get the same info from a Windows system.

I've searched around for a solution, but it seems that most people want this to happen. I would like Windows Search to start up in Automatic mode on this machine. I set the service to Automatic, start it, and all is well. But...when the system restarts the service is set to Disabled startup mode. I don't know what process, or boot setting, or whatever it may be is causing this to happen. Event Log yields no suspects either.

Can any one here advise on how I might troubleshoot this issue? Any tools, utilities, etc. you would advise? I know about procmon, procexp, and the like, but this seems to be a boot time issue, and I don't know if I can use procmon to trace boot time events.

I'm looking for a/the way to tell if a given WIM was captured from a machine that was sysprep'd with the (equivalent of the) /generalize parameter. Interested in Server 2003 R2 as the source platform (x86 and amd64 architectures).

Server 2008 seems to do something with the Registry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State

Such that we can detect that at WIM mount. However, 2003 does not seem to have this or an equivalent that I can determine.

First timer here. I've searched around here, but haven't found a question like the one I have. Apologies if I missed it.

The challenge at hand: produce a "raw disk image file" from a given WIM file. What I am pursuing so far is to use imagex.exe with the "/apply" operation to take the WIM and lay it down in a directory on a server. That seems to produce all the necessary "stuff" I need in that directory.

How would I take that content and produce a "raw disk image file"? I'm told the definition of "raw disk image file" is a block-by-block copy of the disk image, which I hope is the output of the "imagex.exe /apply" command I use currently, but stored in a single file I can hand back to another system in our solution.

imagex.exe /apply image.wim 1 R:\WimImagePoint

I would like to take the contents of R:\WimImagePoint and produce the elusive (to me) "raw disk image file". ISO is not what they want, nor is anything requiring winPE.

Any pointers? External utilities' references are welcome. Would like to avoid unmanaged code solutions as much as possible, but will entertain them if that's the only route.

Also, I am not married to the idea of imagex /apply as the starting point, it's just the comfort zone so far.