Issues I've come across in SCCM 2012 R2 after migration from 2007
We recently moved from 2007 to 2012 R2... as in 1 week after R2 release. Our consultant didn't know a ton about R2 so we had a few hiccups. I'm going to detail them here and see if any of any of you have any insights into solving them
SILVERLIGHT
We have a sliverlight app that will not print on anything more advanced then silverlight 4. So we decided not to deploy silverlight with the client. Works fine... doesn't last a long time. Silverlight would upgrade or install (if not present) after a day or two. This is with us setting silverlight to NO update (app and registry and GPO) and not having it as part of the updates we download from WSUS. Not everyone uses the SL app but since we can't keep SL from upgrading if they do, we are stuck with two SCCM for the moment. This si problematical at best and using up resources we want to recover.
OSD TS Deployment of Applications
We have a number of task sequences that deploy a mixture of applications and packages. Even though the app will deploy afterwards we have occasional issues where a app will not install as part of the task sequence and there is no indication of anything wrong in the SMSTS.log file. Acts like the app was installed but its not. And if you check all the apps are on the local DP (and validated)... and as I said, I can deploy the app afterwards either separately or as part of another application TS. This tends to happen mostly to APPS, not packages. Office, Streets & Trips, Citrix reciever and a few others. And I'll have two identical machines, running on same port (different time) and one will get everything and one will miss half the apps. Also tried identical machines same time, different ports of same switch with same mixed results. These are all apps built form migrated packages; at most we went in and changed detection method after migration and conversion.
Migrated apps and driver packages
I am NOOB at SCCM, so forgives the NOOBNESS of this statement. I thought that if I took a TS and tried to Distribute Content to a DP or DP group and couldn't then all the apps and drivers were there and working. Same for driver and software packages; I thought if you distributed and didn't hear back, all was good. I found out I was wrong when we sent a DP to a remote site with limited bandwidth and realized the DP was falling back to boss SCCM box in our data center for a lot of (formerly migrated) software and driver packages. Upon diving in I found a good chunk of the migrated packages would not validate and ended up rebuilding the package (for software) and then redeploying (same source for software, same commands and settings just built into a package rather then migrated) and it worked. I am now looking at rebuilding most of our software and driver packages that were migrated.
0 Size Driver packages
I have a number of newly created driver packages that have zero size. I have seen some posts on this but I have not seen a definitive answer. is this a error or is it indicative that the drivers are in other packages?
2007 Pushes
We still have the bulk of the user base on 2007. However, most of the DPs (1 per AD site) have been moved to 2012 and do not work with 2007 anymore. I occasionally have clients in other AD sites fail to get software (will process when downloaded but never downloads). Should l recreate boundaries for each AD site and include the data center DP as a protected DP for each boundary?
I have more issues that I am struggling with but this is enough for now. Any assistance, be they references to other posts or new wisdom, appreciated.
Thanks!
Answers (2)
OSD TS Deployment of Applications:
It has been recommended from SCCM gurus that when you have more than a few applications to install in an TS, they should be Programs, not Applications.
Applications simply have a bad habit of not being installed properly in a TS, while Programs are installed just fine.
If you plan to update any of the programs some time after the client have gotten them, either stick with Programs and loose the benefits of Applications, or make an Application of it as well.
Cumbersome? Oh yes...
OSD TS Deployment of Applications:
It has been recommended from SCCM gurus that when you have more than a few applications to install in an TS, they should be Programs, not Applications.
Applications simply have a bad habit of not being installed properly in a TS, while Programs are installed just fine.
If you plan to update any of the programs some time after the client have gotten them, either stick with Programs and loose the benefits of Applications, or make an Application of it as well.
Cumbersome? Oh yes...
OSD TS Deployment of Applications - I too have had similar issues with deploying applications within OSD TS. I reverted those applications to packages to overcome those issues. - RyRyTech 10 years ago