Pour les professionnels de l’informatique >
Forums - Accueil
>
Configuration Manager Software Distribution
>
weekly/daily software distribution solution help
weekly/daily software distribution solution help
- Hi,
I need to come up with a soltuion to distribute files to many remote clients on a weekly or daily basis and would appreciate some suggestions on the best approach to use.
SCCM is used to manage many remote sites. Each site has 2 BDP's.
All the clients in each site run a custom screen saver application that shows rich content.
Normally on a weekly basis but sometimes daily a new set of screensaver content is released. The content is generally about 20MB in size.
I need to configure SCCM to distribute this content to the appropriate folders on all clients.
The end solution needs to be automated where the publishing team copy the content to a share and a scheduled job running every nght detects the new content and processes it. I have reasonable scripting skills so I can easily make the scheduled job to detect files, move files to specific folders, force a package to be updated on distribution points, change the version of a package, re-run an advertisement etc.
Along with the deployment approach there must be reporting where I can generate a report showing what computers have what release of new content.
A few things I am aware of are:
I would not want the content to build up on the clients so it will need to be cleared from the SCCM cache folder when a new release arrives. If the new release is the same package but re-submitted with new content then a new folder is created in the cache with the source version incremented.
From what I can see, the reporting on a package cannot differentiate between the package version so incrementing this for each new release may not be an option.
Previously this solution has been met using Tivoli. There are a number of complex cmd and vb scripts that run centraly and are ran on the clients. These scripts enable the clients to find the staged source files and copy them to the appropriate folder. Any parts of these scripts could be modified and used in the SCCM solution if required.
Any suggestions on the best way of using SCCM to meet these requirements would be greatly appreciated.
Thanks,
Jim
Réponses
- my opinion (again, just my opinion): I think you're overthinking the package version thing. The client bases what it does on a policy, like an advertisement policy. When you update DPs for a package, the next time the client picks up policies, it will discover it has the wrong version in cache. If there is a advertisement start date for that advert in the future, it will begin to download to cache so it has the latest version.
But I can make up a custom mof edit for sms_def.mof. Wouldn't be too hard. It's all right there in root\ccm\softmgmtagent, in CacheInfo, including version. Give me a couple hours at least. I usually like to test these things before putting them out there.
Edit: try this: http://myitforum.com/cs2/blogs/skissinger/archive/2009/06/16/sms-configmgr-client-package-cache-info.aspx
It worked in my lab. and I found out I have some really old pkgs in cache on my lab clients. I should probably send out a cacheclean script myself. :-)
Standardize. Simplify. Automate.- Proposé comme réponseEric C. MattoonMSFT, Modérateurmercredi 17 juin 2009 00:53
- Marqué comme réponseEric C. MattoonMSFT, Modérateurmercredi 17 juin 2009 14:33
I think everything you're trying to reverse engineer here is overkill. lol
If the package version isn't the correct one, the advert will report "waiting for content" for that particular box until the right version is available and downloaded & used.
You can of course script anything you want... you could build into your script to check for package version independently, and put that somewhere in regkey or wmi. But honestly... you're just making work for yourself.
If the client happens to be broken enough to not be able to figure out it needs an updated package version, it's also broken enough to either a) not run the advert at all, or b) if you did build in logic into the vbscript, you'd be testing against it's bad data anyway, and it likely couldn't even *report* that it was messed up... if it was that messed up.
I think you're way overthinking this whole process.
fyi... if you find you don't need that mof edit -- remove it or change it to FALSE. It's a lot of data cluttering up your DB for no good reason in that case.
Standardize. Simplify. Automate.- Marqué comme réponseEric C. MattoonMSFT, Modérateurmercredi 17 juin 2009 14:32
Toutes les réponses
- Hi Jim,
I don't see any reason why you should change your Tivoli approach. If it worked there I would run the same cmd/scripts with Config Mgr. Having said that perhaps you should take a close look at the SDK. It documents how you can script the creation of packages, advertisements and other objects. The SDK kcan be downloaded here - http://www.microsoft.com/downloads/details.aspx?FamilyId=064A995F-EF13-4200-81AD-E3AF6218EDCC&displaylang=en
Kent Agerlund | http://agerlund.spaces.live.com/blog/ - Hi Kent,
I have looked at the SDK and am able to automate packages and advertisements however there are still various approaches I could take.
Even using the Tivoli scripted approach I have various approaches.
A. Do I use a single package and scheduled assignemnt and just update the source/dp's and maybe the version for each release. If I take this approach will it be easy to track success in reports
B. Do I create new packages/assignments every time and remove the advertisement for the previous one. This means packages will build up on the DP's.
C. Do I have scripts that run on clients expecting the source to exist in the local cache. If so I need to consider flushing the cache
D. Do I have scripts that run on clients that look for the source in the shares on the BDP's. This way I will still need to flush the package source on the BDP's
I thought maybe there is an ideal approach for SCCM utilising some featutres I may not have considered.
If I still need a complex approach with many inteligent scripts then any suggestions or ideas about this would be appreciated.
Thanks,
Jim - My opinion. I could be wrong (often am). :-)
a) use a single package. Theoretically, if you update the DPs at 6pm, and the clients have been instructed to re-run the advertisement (script) at 6:30pm, the client's will know to go get the latest version of the package.
b) No, I wouldn't create new ones. Sounds like make-work to me.
c) Whatever program you have within the advertisement will already be checking for the latest version of the DP content. Yes, it will expect the cached package version to match what the MPs are telling the client it should be. But if it doesn't match, it'll go get the latest version and download to cache. You shouldn't have to build in more intelligence into your script.
d) Again, nope: the MPs offer the policy to the clients for the advertisement. Within that Advertisement policy will be a DP version it should expect to find. You don't need to reinvent the wheel.
Regarding cache cleanup on local clients. "theoretically" the ConfigMgr Client will clean up it's own backyard using 'tombstoning' rules, and first -in first -out rules. But you'll hear many stories where theory doesn't match reality. If you notice that, then perhaps you might want to consider a 'general maintenance' task of say... weekly or monthly... that simply runs a cacheclean script on the clients (not from cache-though... using "run from dp", because it can't clean up the cache if it's being run from cache. :-)
Standardize. Simplify. Automate. - Hi Sherry,
Your suggestions sound OK and the info about cleaning the cache by running a package from the DP is useful as I would have discovered this the hard way.
My only concern with this approach is reporting. I would like to report on what release of content each client has. If a new package was created for each release the reporting would be easy however I am unsure how to do this when the same package is updated and re-used.
Thanks. - my opinion (again, just my opinion): I think you're overthinking the package version thing. The client bases what it does on a policy, like an advertisement policy. When you update DPs for a package, the next time the client picks up policies, it will discover it has the wrong version in cache. If there is a advertisement start date for that advert in the future, it will begin to download to cache so it has the latest version.
But I can make up a custom mof edit for sms_def.mof. Wouldn't be too hard. It's all right there in root\ccm\softmgmtagent, in CacheInfo, including version. Give me a couple hours at least. I usually like to test these things before putting them out there.
Edit: try this: http://myitforum.com/cs2/blogs/skissinger/archive/2009/06/16/sms-configmgr-client-package-cache-info.aspx
It worked in my lab. and I found out I have some really old pkgs in cache on my lab clients. I should probably send out a cacheclean script myself. :-)
Standardize. Simplify. Automate.- Proposé comme réponseEric C. MattoonMSFT, Modérateurmercredi 17 juin 2009 00:53
- Marqué comme réponseEric C. MattoonMSFT, Modérateurmercredi 17 juin 2009 14:33
- Hi Sherry,
The MOF sample works OK and I can use a custom report to show the version of a package in the cache
My concern with this is just because a package exists in the cache does not mean it was applied successfully.
The package will consist of content files and a script. The script will copy the files to the appropriate folders. This means I need report on the version that was successfully applied.
I guess I could make the script within the package write a version to a custom registry key or custom WMI class then I could use SCCM to report on that. Does this sound like a good idea or am I in overkill mode again ?
Thanks. I think everything you're trying to reverse engineer here is overkill. lol
If the package version isn't the correct one, the advert will report "waiting for content" for that particular box until the right version is available and downloaded & used.
You can of course script anything you want... you could build into your script to check for package version independently, and put that somewhere in regkey or wmi. But honestly... you're just making work for yourself.
If the client happens to be broken enough to not be able to figure out it needs an updated package version, it's also broken enough to either a) not run the advert at all, or b) if you did build in logic into the vbscript, you'd be testing against it's bad data anyway, and it likely couldn't even *report* that it was messed up... if it was that messed up.
I think you're way overthinking this whole process.
fyi... if you find you don't need that mof edit -- remove it or change it to FALSE. It's a lot of data cluttering up your DB for no good reason in that case.
Standardize. Simplify. Automate.- Marqué comme réponseEric C. MattoonMSFT, Modérateurmercredi 17 juin 2009 14:32
- Thanks for your help sherry.
I always go to deep into a solution and it helps to discuss ideas with someone.
The end solution will be:
1. A sheduled job on the sccm server will run a script to look for new files in a pickup folder.
2. If there are new files these will be copied to the source folder for an existing package, a VB script will update distribution points for the package and a VB script will add a new mandatory assignment to the package advertisement.
5. The SMS_DEF.mof will be edited to include the client cache details.
6. A custom report will be created to report on the latest version of the package in the client cache.
7. Once every month or two a package will be advertised containing a script to clear the client cache. This package will run from the DP.
Unless you reply with any more comments, I will start putting this together tomorrow
Thanks again
