ID-10-T

After seeing the original "Let's see your Fish" thread, I thought I'd segue into a somewhat related topic and one of my favorite activities when I'm not parked in front of a computer ... fishing! I can't be the only angler out there, so let's see your fish! I'll start off with one my 7-year old daughter brought in last summer. This is her biggest yet and she had to get help from one of her school peers to bring it in while dad tried to capture the moment (faces blurred for privacy).

Good morning, all, Once again, thanks to everyone for pitching in to stop my crying. I'm happy to report that applications are now deploying correctly during OSD thanks to an increased cache size (I had to bump it up to 60 GB). I was already aware of @free780's suggestion to use a UNC path but our network consists of a couple of tin cans and some string, so the impact while trying to deploy to 60+ machines would have the network guys breaking out the pitchforks. So, unfortunately, not an option for me. But the issue seems fixed now, so thanks again to everyone for helping me out.

@Arthur, I owe you a beer or ten. The cache size looks like the root of the issue. During task sequence deployment it is set at the default 5 GB. I have the client set to enlarge it but that doesn't appear to take effect until the entire process has completed. The article you linked to gave me the missing clue: SMSCACHESIZE. I enlarged the cache to 50 GB and the applications deployed successfully with the exception of Visual Studio 2017. Sadly, the VS installation files are ~40 GB and even a 50 GB cache just doesn't have the space to deal with it alongside all the other software. My test machine has the space to spare so on Monday, I'll bump up the cache size to "ridiculous" and see if VS works; I'm betting it will. Thank you to everyone for your help! Have a great weekend!

No joy! Deployment of some applications continues to fail when deployed during a task sequence but continue to roll out successfully via Software Center. I'll move on to @MartinByard's suggestion about removing and re-adding the applications to the task sequence and see how that works. Poking through the logs again, AppEnforce doesn't reference the failed applications at all, however, AppDiscovery does contain references with errors before moving on to the next application (the task sequence is set to continue if it encounters errors). For ease-of-reference, the task sequence should be installing in the following order: ArcGIS Pro, Google Earth, Java JDK, Matlab, SPSS, Visual Studio, and Windows SDK. Everything works up to Java JDK, then errors out on subsequent applications until it gets to the Windows SDK which installs successfully. In the meantime, for your sleep-inducement pleasure, I'll attach the AppDiscovery and AppEnforce log files. I also have AppIntentEval and SMSTS logs, if you're still awake. AppDiscovery.txtAppEnforce.txt

Thanks for the replies, everyone. I'm running another test based on some of the suggestions. I've updated to SCCM 1810 now so that may solve the problem as well...fingers crossed. I went through a subset of the applications that are problematic and ticked off the "Allow the application to be installed..." option, per @Whisky's suggestion. Some of the problem applications did have this flag set already so I'm not sure it will help but it's worth a shot. Also, per @Whisky, I've updated the content. I had done this previously (hence the many revisions for some of the software) but doing it again (shouldn't) hurt anything. I haven't tried @MartinByard's suggestions yet, but it's next on the list. I remain cautiously optimistic that this test will work flawlessly and I can get back to drinking coffee and watching YouTube videos.

I’m desperately in need of assistance in troubleshooting a deployment issue I’m encountering here. I’m hopeful that one of the SCCM experts here can help me out... I have a million and a half applications (not packages) shoe-horned into SCCM for deployment to various labs across our university. When I deploy the applications through Software Center, everything works great. However, when I try to deploy them as part of an operating system deployment task sequence, many of them fail to deploy. The operating system itself deploys fine and at the end of the process, I have a fully functional system minus the apps that failed. Not all fail, but many do. I’ve read the various logs until my eyes begin to bleed and I think I’ve found the problem but I’m not sure how I can correct it. Because I’m new to this whole SCCM thing and I’ve had to figure it out as I go, I have many, many, many applications that are high on the revision scale due to my numerous trial-and-error packaging attempts. For example, Matlab 2018b is currently sitting at 14 revisions. This is one of the applications that fails to install correctly. Peering at the logs, AppEnforce is referencing revision 11 and failing to install the application. I’m convinced it would work if it tried for revision 14. Can anyone tell me why this might be happening and how I can resolve it? Why is SCCM trying to deploy an older revision instead of the latest and greatest? I’ve seen several reports of this happening with older SCCM releases but apparently the issue was addressed and resolved in the 1802 and later builds. We are currently running on the 1802 build and the update to 1810 is running as I post this. Hopefully, I can report back shortly that the issue has been resolved but just in case…if anyone can help me out, I’d be most appreciative. If you need logs, let me know and I can throw ‘em up for your perusal. Thanks.

Xerox also adds this "feature" without asking nicely. I've tried the above registry hack and it works on our 1709 builds but doesn't seem to work on our 1803 builds. We haven't moved up to 1809 yet, so I can't say what happens there. I haven't tried AppLocker but if that works, it's on my radar now. Seems to me there used to be a Lexmark one as well, but I haven't seen it in awhile. There's been some concern from our printer team that these utilities may, at some point, cause issues with the embedded print system we use although that hasn't actually happened yet that I've heard.

Howdy, peoples! I thought I'd share my experience with packaging and deploying Clicker 6 using SCCM. This process may also work for Clicker 7, but since we aren't licensed for it I haven't tested it. Clicker 6 doesn't play well with SCCM for standalone deployment and the network installation relies on UNC paths to network shares. Neither of these options is workable for me so here is my own hybrid solution to deploying Clicker 6: Part I: 1. Create a working directory and create three(3) subdirectories: Installer, MSI and Resources. 2. Share the Resources directory so it's accessible from the network; this is a temporary step required for the process to complete. 3. Locate your Clicker6.exe file and extract it to the Installer directory. 4. Run Setup.exe, choose the "Install Clicker on a computer network"option and click Install. 5. Follow the bouncing ball and enter your serial number when required. 6. The Network Installation Point will be the MSI directory. 7. The Shared Files Path must be a UNC path to your Resources folder. 8. Choose the option to install the Xiph Codecs and select/deselect any additional options you want. 9. Select "Activate Clicker during installation", accept the license and allow Clicker 6 setup to complete. Part II: Go ahead and unshare the Resources directory. You can also delete the Installer directory or, better, back it up to a safe place. Going forward, we only need the MSI and Resources directories. Drill down into MSI\Config and open the "Installinfo.ini" in your editor-of-choice. This file contains some of the options yous elected during Part I above as well as some additional network options that we are not interested in. Play with the other options if you want to change some of your selections from Part I but what we are interested in is the NETWORKINSTALLMODE= switch. Mine was set to"Workstation"and "Laptop"was commented out. Flip those two so "Laptop"is enabled and "Workstation"is commented. Laptop mode configures Clicker 6 to run locally and offline; no more network dependencies! Save your changes and exit. Part III: From here, running the "MSI\Clicker6-en.msi" file will install Clicker on a local system. You can run this file directly and follow the bouncing ball or you can package up both the MSI and Resources directories for silent installation with your preferred method of distribution. I'm deploying with SCCM and Powershell Application Deployment Toolkit (PSADT) so I copied the aforementioned directories to the PSADT Files directory and edited the Deploy-Application.ps1 file to drill down into the MSI directory and run "Clicker6-en.msi" with the good old /QN switch. During my testing, I found the installer will also let me change the installation path using INSTALLDIR="\path\to\new\location" so it's possible other switches may work as well, however, I haven't tested anything. Hopefully, someone out there finds this write-up a somewhat useful guide. Otherwise, please feel free to entertain yourself by correcting my spelling and grammar. I have a few more of these How-To guides on my radar for some of the more challenging software I encounter so let me close up this article by asking: is there a better place to post these types of guides or should I just post in what I believe is the most appropriate forum for the specific guide in question...? Anyway, thanks for indulging me, folks!

We have collections sorted by lab, department, staff, faculty, etc....a veritable collection of collections. Software, likewise, is organized by essentials (stuff everyone gets), departments and labs. When my money finally gets here from Nigeria, I want my replacement to be able to step in and take over with minimal learning curve. Inside the SCCM Console, everything is neat, tidy and reasonably organized. I'm trying to keep the back-end similarly neat and tidy. For the most part it is but there are a few applications that just don't like my organizational structure...always a rebel somewhere. I can hang things off the root and (probably) solve the problem but that starts to get ugly and out-of-hand with too many exceptions. My take-away from all of this is that I'm doing things pretty much the same as others and I've just been unlucky enough to hit several problem applications in a short time. Creativity is king, so I'll find away to have my cake and eat it too; I'll try repackaging the software and see if that works. Stay tuned for updates. Same bat-time, same bat-channel...

Good morning, folks, I wanted to get an idea how people structure their application shares for deployment via SCCM. This task has recently fallen to me here at our university and I am well under way with regard to packaging and deploying software to faculty, staff and lab environments. I'm relatively new to SCCM (and mass deployments in general) with no training, so it's been a lot of research and trial-and-error to get as far as I have. It's been working well so far, however, in the last few weeks I have hit a couple of hurdles that have me rethinking how I do things. Most annoying is the path length limitation that's sandbagged a few of my applications. Similar to another thread I saw here, I use a path like "$SHARE\XYZ\Vendor\Product\Architecture\Version", where XYZ is a directory for either for default applications or lab-specific software. This works for, probably, 99% of the stuff I deploy but lately I have had at least three (3) applications that fail due to long path/filenames. I should add that I use Powershell Application Deployment Toolkit (PSADT) so that adds an additional subdirectory (Files) beneath the Version directory. So how are others structuring their application paths for SCCM deployment? Do most people use a structure similar to mine or do they dump everything into one share? Is there an actual "best practice" or do folks just go with whatever works?

AppDeploy is pretty basic but it can create MSI-based installers. WIX Toolset can do some pretty elaborate things but it relies on Visual Studio and it's almost entirely command-line driven. Polish up your coding skills...you'll need 'em. There are also numerous EXE-based kits out there (NSIS, INNO, etc) if you don't specifically need MSI format. I've tried a few commercial products for both MSI and EXE and I've had mixed results with pretty much all of them; steep learning curves, unpredictable results, etc. Since I'm deploying software using SCCM, I find it easier to just use the Powershell Application Deployment Toolkit (PSADT). If you're looking to deploy Google File Stream this is might be a better option for you (this is what I used for File Stream in our environment).

Greetings from the Great White North! Been here a few times over the years lurking and collecting information. Seems about time to join the party and maybe give back a little.