Package downloading to client problem
- Hello. I have created a couple of "snapshot" msi's using both ScriptLogic's MSI Pro as well as Admin Studio SCCM Edition. Basically I am trying to use the repackager program within these tools to take legacy installations and turn them into MSI's. When I create the program and point to a drive letter using msiexec and don't use "source files" within SCCM, the install will work just fine. The problem that I am having is I choose the source directory on the network where the MSI and other files are located and then choose the actual MSI from that folder. I am new to this, but this is the way I think it needs to be done in order to have SCCM automatically updated my secondary sites (distribution points). If I don't do this, then I will be copying the source folder between all network locations manually. Anyways, the problem I have when I choose that this package has a source directory is that when the client tries to download the package locally and then run, the package just barely starts downloading and hangs up. I have checked all the logs that I can find and everything shows that it is successfully download, but it really isn't. Any suggestions from those of you that are more familiar with SCCM?
Thanks
Answers
- If you do not see the package in the client cache, can you check the following logs to see if there are any errors related to that packageID?
CAS.log
ContentTransferManager.log
DataTransferService.log
It could be possible that the package was downloaded successfully using BITS but the hash verification failed for some reason. The above log files should log the error.
Thanks,
Bhaskar- Marked As Answer byEric C. MattoonMSFT, ModeratorWednesday, November 11, 2009 2:33 PM
All Replies
- It sounds as if this is not a ConfigMgr related problem. Have you tried a msi like the ConfigMgr toolkit (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=948e477e-fd3b-4a09-9015-141683c7ad5f)? That one can definitely be installed using a DP or download & execute.
See execmgr.log on the ConfigMgr side and the log that your msi produces for further troubleshooting. Here is the execmgr log from when I kicked off the download of the custom MSI I created:
Verifying content availability for package FDL00062 optional program EIS 12.6 execmgr 11/5/2009 7:06:40 AM 3416 (0x0D58)Requesting content from CAS for package FDL00062 version 1 execmgr 11/5/2009 7:06:40 AM 3416 (0x0D58)
Successfully created a content request handle {32FD6866-AFCE-4867-AB73-AA427DACD862} for the package FDL00062 version 1 execmgr 11/5/2009 7:06:40 AM 3416 (0x0D58)
Content availability verification for package FDL00062 program EIS 12.6 is in progress execmgr 11/5/2009 7:06:40 AM 3416 (0x0D58)
Content for optional program is now available. The location request ID is {32FD6866-AFCE-4867-AB73-AA427DACD862} execmgr 11/5/2009 7:06:40 AM 1108 (0x0454)
Validating chain of dependent programs for package FDL00062 optional program EIS 12.6 execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Validating package FDL00062 program EIS 12.6 in the chain. The content request ID is {32FD6866-AFCE-4867-AB73-AA427DACD862} execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Creating an optional execution request for package FDL00062 program EIS 12.6 execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Execution Manager timer has been fired. execmgr 11/5/2009 7:08:41 AM 552 (0x0228)
Requesting content from CAS for package FDL00062 version 1 execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Successfully created a content request handle {47B9D877-2B8C-406A-AE7A-81E9F148E207} for the package FDL00062 version 1 execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of SoftDistWaitingContentEvent
{
AdvertisementId = "FDL20092";
ClientID = "GUID:F4E064C0-1235-4AA3-8E93-A80CEC24FEC4";
DateTime = "20091105130841.650000+000";
MachineName = "SNAPSHOT";
PackageName = "FDL00062";
PackageVersion = "1";
ProcessID = 220;
ProgramName = "EIS 12.6";
SiteCode = "FDL";
ThreadID = 3836;
};
execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)Successfully raised SoftDistWaitingContentEvent event for program EIS 12.6 execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Raising event:
[SMS_CodePage(437), SMS_LocaleID(1033)]
instance of SoftDistWaitingContentEvent
{
AdvertisementId = "FDL20093";
ClientID = "GUID:F4E064C0-1235-4AA3-8E93-A80CEC24FEC4";
DateTime = "20091105130841.681000+000";
MachineName = "SNAPSHOT";
PackageName = "FDL00062";
PackageVersion = "1";
ProcessID = 220;
ProgramName = "EIS 12.6";
SiteCode = "FDL";
ThreadID = 3836;
};
execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)Successfully raised SoftDistWaitingContentEvent event for program EIS 12.6 execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
Execution Request for package FDL00062 program EIS 12.6 state change from NotExist to WaitingContent execmgr 11/5/2009 7:08:41 AM 3836 (0x0EFC)
- The machine is not able to locate content (IOW the package on a DP) and the installation was not kicked off yet (according to the logfile). Make sure that the package made it to at least one DP (see package status in the admin console) and that you have set up the boundaries and advertisement (local / remote behavior) right.
- It successfully made it to the one DP that I assigned it to, which is on the local LAN (same as the client trying to download). Advertisement is setup correctly as well as the boundaries. Like I said all other packages download and run just fine.
- Anyone else have any suggestions?
Thanks This is a suggestion, purely a shot in the dark so take it FWIW. You might want to check the WMI repository on a sample machine that is exhibiting the problem. It could be that WMI is corrupt. There are tools for validating and correcting WMI. Might need to re-install the client afterwards.
- If you do not see the package in the client cache, can you check the following logs to see if there are any errors related to that packageID?
CAS.log
ContentTransferManager.log
DataTransferService.log
It could be possible that the package was downloaded successfully using BITS but the hash verification failed for some reason. The above log files should log the error.
Thanks,
Bhaskar- Marked As Answer byEric C. MattoonMSFT, ModeratorWednesday, November 11, 2009 2:33 PM
