Tuesday, July 20, 2010 7:53 PM
I have a command scheduled to run at oobeSystem (pass 7), but there is no evidence of it even being run...erroneously, or otherwise.
I'll try to describe what i think are pertinent details of my implementation, thus far.
I created a configuration starting with the IE, WMP, RD template (assuming this to be one of the more user-friendly configs) I included most of the optional dependencies, and at least resolved al lthe other dependency issues.
I then added my product installation to the DS under "...DS\$OEM$ Folders\Custom Files\$OEM$\$1". Let's call it MyInstall.msi.
Next I added a synchronous command to call "C:\MyInstall.msi /qn [some other options]" and configured it to run during the oobeSystem (pass 7) pass.
Under "tools > create media", i selected "Create IBW Image with full distribution share". I placed this image on a partition on the target machine. I created a bootable USB flash device using these instructions:http://msdn.microsoft.com/en-us/library/ff795043.aspx), then added the answer file to it.
I booted to my bootable flash drive, browsed to the partitions with my IBW image on it, and ran setup.exe. I selected "Apply answer file or WIS" and then selected the answer file from the usb drive.
Installation completes, and i answer the input language and time zone questions...but there is no evidence of my installation being run. I don't want to presume that this is the cause, but i did find the following lines in the cbs_unattend.log file:
2010-07-20 11:27:54, Warning DISM DISM Provider Store: PID=1524 Failed to Load the provider: F:\IBW\Sources\WimProvider.dll. - CDISMProviderStore::Internal_GetProvider(hr:0x8007007e)
2010-07-20 11:27:54, Warning DISM DISM.EXE: Failed to load WimManager. Try running from the Deployment Tools Command Prompt. If the issue persists, ensure that wimgapi.dll and wimserv.exe are up to date.
2010-07-20 11:27:54, Warning DISM DISM.EXE: Failed to add any commands.
If this could be part of the problem, then why wouldn't the media creation process not include files that it "knows" are necessary parts of the installation? Why couldn't it detect that the associated component is a dependency? When i search the distribution share for that file, it finds it as a part of "Windows Embedded Edition/files" so why wouldn't the installation know where to find it? Does it have anything to do with the name/location of the answer file?
Wednesday, July 21, 2010 3:01 AM
Try the Create IBW Disk from Answer File option instead. Create IBW disk with full distribution share essentially just gives you the full wizard disk. It does not include your 3rd party files or your answer file.
If you create from answer file, then you create what's called a configset. The configset includes your answer file, only the packages required for your configuration, and any 3rd party files you added. It also drops your answer file at the root of your IBW disk so that it automatically runs when the DVD/USB drive is loaded.
- Marked As Answer by _Kelter Wednesday, July 21, 2010 7:58 PM
Wednesday, July 21, 2010 4:22 PM
I did as you suggested, but still no evidence of the command being run. Can you explain these lines?
2010-07-21 07:30:16, Error DISM DISM MSI Manager: PID=1936 Failed copying from D:\Windows\System32\Msi.dll to D:\$WINDOWS.~LS\PackageTemp\eab66882-3cc7-434a-8de7-ccd054009b3b\B2E47F4E-7311-4210-9D32-4E336592A171\Msi.dll - CMsiApi::Initialize(hr:0x80070002)
2010-07-21 07:30:16, Error DISM DISM MSI Manager: PID=1936 Failed to find Offline Aware MSI.dll from image(D:\Windows), hr = -2147024894 - CMsiManager::Initialize(hr:0x80070002)
2010-07-21 07:30:16, Warning DISM DISM Provider Store: PID=1936 Failed to call Initialize method on IDismServicingProvider Interface - CDISMProviderStore::Internal_LoadProvider(hr:0x80070002)
2010-07-21 07:30:16, Warning DISM DISM Provider Store: PID=1936 Failed to Load the provider: D:\$WINDOWS.~LS\PackageTemp\eab66882-3cc7-434a-8de7-ccd054009b3b\B2E47F4E-7311-4210-9D32-4E336592A171\MsiProvider.dll. - CDISMProviderStore::Internal_GetProvider(hr:0x80070002)
Also, what's the D drive being mentioned in these scripts? Should that be the target drive? does it make sense that this would be "D:"? After booting to the new image the target partition is C, and the source partition is F:.I should note that msi.dll belongs to the windows installer package which is included. MsiProvider.dll is part of the Windows Embedded Edition\files. Obviously that's also included.
I also found the following lines:
2010-07-21 07:27:12, Info IBS ==== Executing Synchronous User-Provided Commands ====2010-07-21 07:27:12, Info IBS STATUS: SUCCESS (0x00000001)
But I'm not sure which pass that is from.
NOTE: I still booted from the UFD, and launched setup.exe from another partition on the target machine. After setup began, I pulled the UFD...otherwise the machine would try to boot from the UFD after restarting instead of resuming setup from the target partition...
Wednesday, July 21, 2010 6:51 PM
Can you upload your entire Panther directory? Many people use SkyDrive: http://livefeed.hollywoodreporter.com/2010/07/damon-lindelof-on-inception-ending-pic.html
Also, are your files being copied to the device? Does C:\MyInstall.msi exist?
Wednesday, July 21, 2010 8:13 PM
Okay, it seems that you accidentally lead me to the answer. I was not using a direct path to the file as i was trying to use the "$OEM$\$1..." not knowing if the system drive would ALWAYS be C:\. I also made a bad assumption, which is that the command being called would appear somewhere in the log files. I thought that would give me a hint as to why the installation wasn't happening.
Thank you so much for your time. Now I just have two really quick questions:
If i wanted to use $OEM$\ which is for setup files, can i assume that such files get cleaned up after everything is done?
If so, how would I reference that location from a synchronous command?
Wednesday, July 21, 2010 8:21 PM
OEM folders are not cleaned up after installation. OEM folders are really meant to be used to copy files to your device. We don't currently have a way to determine if you wanted to copy over MyDeviceBackground.bmp to a certain location (don't delete my OEM files) or if you wanted to run an MSI and don't care about the MSI being on the end image (delete my OEM files).
We realize this process is fairly clunky, and we're thinking of ways to improve it in future versions.
For now, to make sure MyInstall.msi is not on your end device, you can add another synchronous command to delete the file post-install, or you could try to manually copy your MSI onto your USB drive outside of an OEM folder (so it isn't copied), then point your synchronous command to run the MSI off of the USB drive. You may run into differences in drive letter problems.
Wednesday, July 21, 2010 9:24 PM
One problem with adding another synchronous command to follow the msiexec call is that msiexec launches another process asynchronously, and then returns. So that leaves us with the option to either (1) create an executable that monitors running processes and waits until msiexec is no longer listed, or (2) put the installation on a flash drive and contend with the unpredictable drive letter issue.
This is less of an issue for us as it might be for our OEM customers. In theory they'd only need to run the full image builder wizard once, and then generalize and clone. I'd give WES7 credit for supporting that scenario!
In this article "http://msdn.microsoft.com/en-us/library/ff794652.aspx" it states that the directory $OEM$ "Contains all supplemental folders and files for an automated or customized installation." If this is the place our customers might use for that purpose, what would be the fully qualified path? Or is it possible to generalize the paths using some "$" path identifiers and such in case for some reason path resolution may differ among images? Or is that a moot point?
Wednesday, July 21, 2010 10:24 PM
You could write a batch file that contains:
start /wait c:\MyProgram.msi
Then have your synchronous command run the batch file instead of the MSI directly. The /wait flag tells the batch file to wait until the MSI exits before processing the next command.
See the ICE help topic "Distribution Shares and Configuration Sets in Windows Embedded Standard 7" for a full set of $ folders you can specify to put files in different locations. $1 means put the stuff on the same drive you installed Windows to.
Thursday, July 22, 2010 2:24 PM
I'm sorry... I didn't specify my question properly. I was asking abotu the full path to the $OEM$ directory on the target machine for the purpose of calling the file. Since the installation location was put in terms of the dollar-sign defined directories, and my attempts to try to call the installer using similar syntax haven't worked, I wanted to know, when calling the file, if a "$OEM$\..." specified directory would resolve to the same path on every target system.
For instance, MyInstall.msi is being installed in $OEM$\$1, and i successfully ran it using "C:\MyInstall.msi", but can i count on this always being the case, or might it, in some cases resolve to "D:\..."? Also, the doc doesn't specify to where the $OEM$ directory would resolve. Does this mean that, too, might change in the future? I also don't know the path to which $OEM$ presently resolves, either. The other's all make sense as long as the system drive will always be C: as they are all relative thereto.
We do have something that works, so thank you again for all your help. i'd just like to be able to generalize the command line so as not to create an unnecessary maintenance hazard.
Thursday, July 22, 2010 6:06 PM
Not sure if this helps, but check out these links that describe how $OEM$ folders are resolved:
Thursday, July 22, 2010 9:36 PM
Hopefully the guides beemr007 posted will help a bit.
Specifying $OEM$\$1 will point to the system drive. I think we did some experiments in the past and found that we couldn't get Vista or Win7 to come up as any drive letter other than C. I believe the OS remaps itself to C no matter what drive configuration you specified. For example, if you install two copies of Win7 on one computer, both of them will show itself as C: on boot, with the other install mapping to another drive letter.
If you want to make sure your files are copied to the C drive though, you can do $OEM$\C\Myfiles.
- Marked As Answer by _Kelter Tuesday, July 27, 2010 10:11 PM
Tuesday, July 27, 2010 10:11 PMThank you both so much!