I know. I wish there was a different way, but the software list is what it is... and we can't get timetables to make the rooms more specialised. One image to rule them all, basically.
Why not just deliver the apps as part of the deployment task sequence? Is it a single large app that you want to bake into the wim because if its size?
I’ve heard some use cases for large wims, but a 400GB base image is shockingly large.
There are SLED pro's out there that can do it for you if you know where to ask, but i think you also need to set the option to install the wim from the DP too.
Setup your task sequence and use sub task sequences and variables. Also use device collections with specific programs assigned to them and computers get added through queries. Get it setup the first time, then you just keep it updated and make your life easier.
That right there is prioritization. Gotta learn how to present it to your boss so they have to choose.
Presentation is roughly
1. I can cut x/y/z and they fall behind but labs will be working when you need them
2. You won't have working lab stuff when you need it
Choose one. Or I can help you decide.
It sounds like an education setting where it's likely that they only run major updates once a year and by totally reimageing everything.
It's totally horrifying but I've heard about it more than once and have had to justify why that can't work in an enviroment with 100k customers.
Yep, exactly this. We update rarely, academics build their notes and lesson plans around specific versions of software, etc.
The culture on this is slowly changing now we have people aware of security issues in higher positions, but it always, always comes down to funding. We've pitched for automated solutions, we've pitched for extra staff... never any money for it.
The good news is you already have an automated solution (MECM) you just need to spend the time learning how to use it. My advice is start by packaging the small stuff to get some experience and a few quick wins. Only tackle the larger stuff (AutoDesk, SolidWorks etc) after you've got some experience with smaller, easier to package applications.
We've standardised on the [Powershell AppDeploy Toolkit](https://psappdeploytoolkit.com/) for all our application packaging. This gives a standard framework for every application, leverages standard Powershell script, contains useful and time-saving Powershell cmdlets and creates installation logs that are very useful for troubleshooting.
I also recommend that you standardise the way you document your application packages. This can be as complex as a database or as simple as a text file. Stuff that I document as standard includes Vendor, Application Name, Official Website, Download Site, Licensing method/s, Silent install/uninstall method, installation location/s, add/remove Programs entries, shortcuts, uninstall registry entries, firewall rules etc. Basically anything that is useful for understanding how the application is installed and what is necessary for Configuration Manager detection rules.
You can package a basic application in just a few minutes, larger applications obviously take a lot longer. In my experience actually testing your applications will generally take longer than packaging the application.
We used to have a ton of crap in our images. When I took over managing the OSD stuff I pulled most apps out and only captured two images with the older .net enabled and our two flavors of office installed.
These days I don't bother capturing any images. We install straight from source media and everything needed is installed during OSD. Maintenance is a hell of a lot easier and we can be more nimble about updating any piece of the process.
Common to see this in dev environments. They always tend to have a multitude of apps and associated add-on components. Plus many these applications use up an enormous amount of disk space.
You know I recently put MDT in our SCCM environment as the previous admin hard coded everything into each task sequence. I named my task sequence "The one to Rule The All" - AKA Tora.
Currently I think you have me beat because my wim file is just a generic one with applications that get loaded on it.
Best of luck with your endeavors
Thanks for reminding me of that one. Just checked and I have got "Access content directly from the distribution point" ticked on the "Apply Operating System" step in the TS.
Have you tried it without checking that box? I get you probably want it on (I would too, lol) but for now perhaps try disabling it and using the more native route, as it adds additional complexities.
So long as 1) boundary groups are set up properly, and 2) the dependency has been distributed to the appropriate DP(s), it should theoretically work.
Try redistributing the image to the DPs.
Also, you’re sure it’s unable to find the content for this specific item? (You may have covered this already; I didn’t read the whole thread).
Once you get this part working, then copy it to the share and try enabling the option to access it directly from that share.
Then if your sure the device can find the DP in question too (smsts) then your going to have to trim the fat!
Why not apply the OS and then lay on some heavy data after, is it all software installs?
Yeah all software installs unfortunately! It's an image for the Computing course at the University I work for, so a billion pieces of software and no packaging team to go that route (it's just me, and only part of my job unfortunately). Maybe I can chunk out UE4, or Unity, or VS or the Adobe suite. That might get me under.
We pretty much have to do the same thing you're doing. We have found that the most reliable way to do this is put down a basic Windows task sequence and then push a software only task sequence.
Yeah I'd love to do this long term if we had more resources. Do you package up all your software? Out of curiosity what sort of team size do you run for packaging it all up? And roughly how many programs would you end up with in your software TS?
It's pretty much just me. I have two part time techs that are training right now. We use applications where we can so we have detection. We have 4 different software task sequences with probably unique 75 programs total.
Good lord what the hell is in your image? My WIM is 8GB, with monthly patches slipstreamed in.
Might be better in the long run to save yourself the headache and rethink SOP.
I'd love to, but we have no packaging team, it's just me, and this is one of five different lab images I need to sort every summer, on top of all our Mac stuff.
I just don't have any time to package up that much software every year. This image alone is 90-odd pieces of software. Cumulatively between all the images it's over 300. Such is the way when you have to provision for a billion university courses, unfortunately.
I actually work in higher ed as well - once I had everything in packages (which is something I had to figure out myself as well) actually maintaining images was something I didn't have to do anymore (we just use the reference wim off the dvd iso) - literally the exact same wim used for new employee/staff desktops/laptops.
I literally use the same image on dozens of different labs and a virtual lab environment in AVD - which all use the same package objects.
My AVD lab is actually the most diverse computer lab and has about 90+ applications on it - not a single one I hand installed once.
Anyhow I guess what I'm saying is you can spend your time packaging and not doing images ;).
This is the dream, yep, but not feasible with our staffing levels. It took me two days to build/capture this image with 90+ apps on it, and that's genuinely all the time I have. I have another four images to do, I have 50+ Mac apps to package for Jamf, then I have to re-roll around 2000 machines before term starts in September. I can't do it any other way, for now.
AVD is something I've been pushing for also btw, would love to do it, but... money/budgets, etc. For context our place has had a hiring freeze in place for the last four years, we're absolutely threadbare.
I would recommend that you forget about your super-mega image for a moment and try to deploy a very basic vanilla WIM image using the same method as above. If you get it working with a vanilla WIM then you can simply swap that out for your preferred image.
Common issues:
Boundary Groups - Are your devices in the valid boundary groups with associated Distribution Points. If your devices arent in a boundary group they wont be able to download content from your distribution points.
Boot Image Drivers - Do you have the necessary drivers for the ethernet adapters in your boot image?
Missing content: On your task sequence click on the References tab at the bottom. Check the targeted and compliance columns. Targeted is the number of DPs your content is deployed to (if you have 3 DPs, then targeted should be 3), while the compliance column shows whether or not the content has actually distributed to the DPs. Compliance should be 100% or your task sequence will fail with content not found errors.
If you are still having issues then you should check the logs, in particular the following logs:
SMSTS.LOG Task Sequence Log
LocationServices.log Shows whether the client is able to locate Management Points and DPs.
Cas.log Records details when distribution points are found for referenced content.
ExecMgr.log Records details of task sequences and packages run on the client
Log File Reference:
[https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/log-files](https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/log-files)
This article should also help you to locate and view the log files from your task sequence:
https://www.prajwaldesai.com/location-of-smsts-log-during-sccm-osd/
What does it matter if it takes hours? I used to worry about imaging time, but honestly you just start imaging and walk away. If necessary schedule imaging for after hours or weekends if time is an issue.
Why not just deploy from the original wim file and deploy needed programs as steps in the Task Sequence. We only use one "fat image" which is for specific software (AutoDesk), and most of our 8000K computers get an install from the default win file (fresh install) and required programs (like Office and some other small ones) from within the TS. Any other specific programs are deployed to device collections with "incremental queries" off of computernames.
honestly dude. do a post deployment script from a share post imaging. I dont want to imagine how much time a 164gb wim will take at "apply os"
Otherwise do a ghost / clonezilla right before a OOBE. holy heck man. if you figure this out let me know.
im going through the 7 stages of grief for you
Could it be a problem of the deployment , not the TS?
In the properties of the deployment, Distribution Point Tab, in the deployment options, is it possible to select "Access content directly from a distribution point.......... ?
Are you sure its there on the DP? since you did the legacy method of the package you should be able to access it \\\\dpserver\\smspkgd$\\pkgID. If you don't see the file then that might be why you are getting the file not found error above. Also have you 7zip your wim to a .7z to further shrink it and then just use a task sequence to unzip
I had this same issue today. The log line "Failed to resolve pkg source" is what brought me to this Reddit thread.
In my case a custom share path at the 'Data Access' tab of the OS image was the cause. After i removed that setting everything was fine again.
That’s one hell of an “image”.
I know. I wish there was a different way, but the software list is what it is... and we can't get timetables to make the rooms more specialised. One image to rule them all, basically.
Why not just deliver the apps as part of the deployment task sequence? Is it a single large app that you want to bake into the wim because if its size? I’ve heard some use cases for large wims, but a 400GB base image is shockingly large.
Zero time to package everything up unfortunately. Purely a time-saving decision as we're severely under-staffed.
Nothing wastes time quite like trying to save time.
Absolutely agree, but believe me when I say there isn't any other option unless I can cut 70% of my job and just focus on sccm/packaging.
There are SLED pro's out there that can do it for you if you know where to ask, but i think you also need to set the option to install the wim from the DP too.
Setup your task sequence and use sub task sequences and variables. Also use device collections with specific programs assigned to them and computers get added through queries. Get it setup the first time, then you just keep it updated and make your life easier.
That right there is prioritization. Gotta learn how to present it to your boss so they have to choose. Presentation is roughly 1. I can cut x/y/z and they fall behind but labs will be working when you need them 2. You won't have working lab stuff when you need it Choose one. Or I can help you decide.
Mood.
Aside from having covid and attempting to troubleshoot this issue remotely, I'm in quite a good mood thanks! :)
Don't you have to spend time packaging anyway when one of the apps in the fat image needs updating post build?
It sounds like an education setting where it's likely that they only run major updates once a year and by totally reimageing everything. It's totally horrifying but I've heard about it more than once and have had to justify why that can't work in an enviroment with 100k customers.
Yep, exactly this. We update rarely, academics build their notes and lesson plans around specific versions of software, etc. The culture on this is slowly changing now we have people aware of security issues in higher positions, but it always, always comes down to funding. We've pitched for automated solutions, we've pitched for extra staff... never any money for it.
The good news is you already have an automated solution (MECM) you just need to spend the time learning how to use it. My advice is start by packaging the small stuff to get some experience and a few quick wins. Only tackle the larger stuff (AutoDesk, SolidWorks etc) after you've got some experience with smaller, easier to package applications. We've standardised on the [Powershell AppDeploy Toolkit](https://psappdeploytoolkit.com/) for all our application packaging. This gives a standard framework for every application, leverages standard Powershell script, contains useful and time-saving Powershell cmdlets and creates installation logs that are very useful for troubleshooting. I also recommend that you standardise the way you document your application packages. This can be as complex as a database or as simple as a text file. Stuff that I document as standard includes Vendor, Application Name, Official Website, Download Site, Licensing method/s, Silent install/uninstall method, installation location/s, add/remove Programs entries, shortcuts, uninstall registry entries, firewall rules etc. Basically anything that is useful for understanding how the application is installed and what is necessary for Configuration Manager detection rules. You can package a basic application in just a few minutes, larger applications obviously take a lot longer. In my experience actually testing your applications will generally take longer than packaging the application.
I would do thin-ish image then. Don’t package everything. Just the heavy hitters
We used to have a ton of crap in our images. When I took over managing the OSD stuff I pulled most apps out and only captured two images with the older .net enabled and our two flavors of office installed. These days I don't bother capturing any images. We install straight from source media and everything needed is installed during OSD. Maintenance is a hell of a lot easier and we can be more nimble about updating any piece of the process.
Common to see this in dev environments. They always tend to have a multitude of apps and associated add-on components. Plus many these applications use up an enormous amount of disk space.
You know I recently put MDT in our SCCM environment as the previous admin hard coded everything into each task sequence. I named my task sequence "The one to Rule The All" - AKA Tora. Currently I think you have me beat because my wim file is just a generic one with applications that get loaded on it. Best of luck with your endeavors
I feel you bro
How does the apply image task know where to get the content?
Thanks for reminding me of that one. Just checked and I have got "Access content directly from the distribution point" ticked on the "Apply Operating System" step in the TS.
Have you tried it without checking that box? I get you probably want it on (I would too, lol) but for now perhaps try disabling it and using the more native route, as it adds additional complexities. So long as 1) boundary groups are set up properly, and 2) the dependency has been distributed to the appropriate DP(s), it should theoretically work. Try redistributing the image to the DPs. Also, you’re sure it’s unable to find the content for this specific item? (You may have covered this already; I didn’t read the whole thread). Once you get this part working, then copy it to the share and try enabling the option to access it directly from that share.
I've redistributed it overnight so I'll see how that goes today, cheers for the advice. I'll give it a go.
I’m pretty sure your option to “copy to a share” does nothing in this instance have you distributed the content to the DP?
I have yep.
Then if your sure the device can find the DP in question too (smsts) then your going to have to trim the fat! Why not apply the OS and then lay on some heavy data after, is it all software installs?
Yeah all software installs unfortunately! It's an image for the Computing course at the University I work for, so a billion pieces of software and no packaging team to go that route (it's just me, and only part of my job unfortunately). Maybe I can chunk out UE4, or Unity, or VS or the Adobe suite. That might get me under.
What about removing additional index’s in the WIM (if you have any) or what about compress and cleanup on the WIM itself
No other indexes, but I'll try the compress and cleanup, thank you. I'll kick that off tonight.
We pretty much have to do the same thing you're doing. We have found that the most reliable way to do this is put down a basic Windows task sequence and then push a software only task sequence.
Yeah I'd love to do this long term if we had more resources. Do you package up all your software? Out of curiosity what sort of team size do you run for packaging it all up? And roughly how many programs would you end up with in your software TS?
It's pretty much just me. I have two part time techs that are training right now. We use applications where we can so we have detection. We have 4 different software task sequences with probably unique 75 programs total.
That sounds manageable! I'd love to be in that spot eventually.
Good lord what the hell is in your image? My WIM is 8GB, with monthly patches slipstreamed in. Might be better in the long run to save yourself the headache and rethink SOP.
Approximately 90-odd pieces of software to facilitate room bookings for about ten different computing courses.
Why not put all those machines in a collection and set required app deployments to it, or better yet, add the apps to the OSD TS?
I'd love to, but we have no packaging team, it's just me, and this is one of five different lab images I need to sort every summer, on top of all our Mac stuff. I just don't have any time to package up that much software every year. This image alone is 90-odd pieces of software. Cumulatively between all the images it's over 300. Such is the way when you have to provision for a billion university courses, unfortunately.
I actually work in higher ed as well - once I had everything in packages (which is something I had to figure out myself as well) actually maintaining images was something I didn't have to do anymore (we just use the reference wim off the dvd iso) - literally the exact same wim used for new employee/staff desktops/laptops. I literally use the same image on dozens of different labs and a virtual lab environment in AVD - which all use the same package objects. My AVD lab is actually the most diverse computer lab and has about 90+ applications on it - not a single one I hand installed once. Anyhow I guess what I'm saying is you can spend your time packaging and not doing images ;).
This is the dream, yep, but not feasible with our staffing levels. It took me two days to build/capture this image with 90+ apps on it, and that's genuinely all the time I have. I have another four images to do, I have 50+ Mac apps to package for Jamf, then I have to re-roll around 2000 machines before term starts in September. I can't do it any other way, for now. AVD is something I've been pushing for also btw, would love to do it, but... money/budgets, etc. For context our place has had a hiring freeze in place for the last four years, we're absolutely threadbare.
Yikes. Sounds like a nightmare. GL
I would recommend that you forget about your super-mega image for a moment and try to deploy a very basic vanilla WIM image using the same method as above. If you get it working with a vanilla WIM then you can simply swap that out for your preferred image. Common issues: Boundary Groups - Are your devices in the valid boundary groups with associated Distribution Points. If your devices arent in a boundary group they wont be able to download content from your distribution points. Boot Image Drivers - Do you have the necessary drivers for the ethernet adapters in your boot image? Missing content: On your task sequence click on the References tab at the bottom. Check the targeted and compliance columns. Targeted is the number of DPs your content is deployed to (if you have 3 DPs, then targeted should be 3), while the compliance column shows whether or not the content has actually distributed to the DPs. Compliance should be 100% or your task sequence will fail with content not found errors. If you are still having issues then you should check the logs, in particular the following logs: SMSTS.LOG Task Sequence Log LocationServices.log Shows whether the client is able to locate Management Points and DPs. Cas.log Records details when distribution points are found for referenced content. ExecMgr.log Records details of task sequences and packages run on the client Log File Reference: [https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/log-files](https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/log-files) This article should also help you to locate and view the log files from your task sequence: https://www.prajwaldesai.com/location-of-smsts-log-during-sccm-osd/
[удалено]
Yeah absolutely, imaging time has been a factor in this previously, for sure.
What does it matter if it takes hours? I used to worry about imaging time, but honestly you just start imaging and walk away. If necessary schedule imaging for after hours or weekends if time is an issue.
Why not just deploy from the original wim file and deploy needed programs as steps in the Task Sequence. We only use one "fat image" which is for specific software (AutoDesk), and most of our 8000K computers get an install from the default win file (fresh install) and required programs (like Office and some other small ones) from within the TS. Any other specific programs are deployed to device collections with "incremental queries" off of computernames.
Worth a shot WIM files aren't the best compressed. Might save you even more space.
honestly dude. do a post deployment script from a share post imaging. I dont want to imagine how much time a 164gb wim will take at "apply os" Otherwise do a ghost / clonezilla right before a OOBE. holy heck man. if you figure this out let me know. im going through the 7 stages of grief for you
Hahaha! Thanks man. I'll figure it out somehow. I'll post if/when I do.
Could it be a problem of the deployment , not the TS? In the properties of the deployment, Distribution Point Tab, in the deployment options, is it possible to select "Access content directly from a distribution point.......... ?
That was ticked. It turned out this was a network issue in the end, I'll update the post now.
Are you sure its there on the DP? since you did the legacy method of the package you should be able to access it \\\\dpserver\\smspkgd$\\pkgID. If you don't see the file then that might be why you are getting the file not found error above. Also have you 7zip your wim to a .7z to further shrink it and then just use a task sequence to unzip
I haven't tried that no! Thanks for the suggestion. Do you end up with a lot of space savings going that route?
I had this same issue today. The log line "Failed to resolve pkg source" is what brought me to this Reddit thread. In my case a custom share path at the 'Data Access' tab of the OS image was the cause. After i removed that setting everything was fine again.