I was just talking with someone about how “times have changed” just since 2017. Then I found an old email which had a list of cases I was working on around Q1-17 (former employer). Compared to then, 2019 has been much more calm.
ConfigMgr client push account not having permissions on the remote devices.
Over-zealous Antivirus settings getting in the way (McAfee) of ConfigMgr client installations.
Using separate accounts in trusted AD forests, rather than a central trusted account, and the passwords were out of sync.
Another team installed a 3rd party help desk product on the SQL host as SCCM uses, and didn’t tell them it hogs most of the available memory and violates the terms of the ConfigMgr/SQL license.
After suggesting the use of an isolated IP subnet and dedicated DP for a central imaging workbench, the server admin team instead added a 2nd NIC to both the SCCM primary site server and a different DP, on different subnets, one without a gateway, and didn’t tell the SCCM anyone else.
IT staff enrolled several Surface Book’s with EMS/Intune, and then removed the Intune client and installed the SCCM client and then opened a support ticket about why the client no longer shows as “managed” in Intune. Microsoft investigated, explained and closed the request (as they should have). The customer argued to keep the request open. I was brought in to help explain why it should be closed (that alone took 2 days).
Primary site server has CrowdStrike, Symantec EP, and Malware Bytes agents installed, all are active, and none have ConfigMgr exclusions. Long day.
Client Push installation has custom settings which set the default MP to one that was removed from the environment years ago.
Network team re-assigned subnets during an office relocation. No one was notified to update AD sites and subnets or ConfigMgr (site boundaries).
DNS scavenging was turned off, with DHCP lease duration of 3 days and 50% of devices roam around the campus every day or two.
It’s from 2016, so even though it’s a few years old now, it still holds up very well in mid 2019. However, everyone who’s ever worked with that product knows that the list could become a Netflix series.
This blog post is not going to repeat the above; instead, append the list with some things I still see in a variety of environments today. Things which really should be nipped in the bud, so to speak. Baby steps.
Using a Site Server like a Desktop
Don’t do it. Install the console on your crappy little desktop or laptop and use that. Leave your poor server alone. Avoid logging into servers (in general) unless you REALLY need to perform local tasks, and that’s it. Anything you CAN do remotely, should be done remotely.
If installing/maintaining the ConfigMgr console is your concern: forget that. The days of having to build and deploy console packages are gone. Install it once, and let it update itself when new versions are available. Kind of like Notepad++. Nice and easy.
Using a server as a daily desktop workspace not only drags on resources and performance.
It creates a greater security and stability risk to the environment.
The more casual you are with your servers, the sloppier you’ll get and eventually you’ll do something you’ll regret
Whatever your excuse has been thus far, stop it.
Even in 2019, with so many tools floating about like Symantec, McAfee, Sophos, CrowdStrike, and so on, when I ask if the “exclusions” are configured to support Configuration Manager, I often get a confused look or an embarrassing chuckle. Gah!!! Chalkboard scratch!
There are several lists of things to exclude from “real-time” or “on-demand” scanning, like this one, and this one. Pick one. Failing to do this VERY often leads to breaks in processes like application deployments, software updates deployments, and policy updates.
Also important: with each new release of Configuration Manager, read the release notes and look for new folders, log files, services or processes that may be introduced. Be sure to adjust your exclusions to suit.
Ignoring Group Policy Conflicts
Whatever you’re doing with regards to GPO settings, make damned sure you’re not also doing the same things with Configuration Manager. The two “can” be combined (in rare cases) to address a configuration control requirement, and you can sew two heads on a cow, but that doesn’t mean it’s the best approach.
Pick one, or the other, only. If you have WSUS settings deployed by GPO, and are getting ready to roll out Software Updates Management via Configuration Manager, stop and carefully review what the GPO’s are doing and make adjustments to remove any possible conflicts.
And, for the sake of caffeine: DOCUMENT your settings wherever they live. GPO’s, CI’s or CB’s in ConfigMgr, scheduled tasks, whatever. DOCUMENT THEM! Use the “Comments” or “Description” fields to your advantage. They can be mined and analyzed easily (take a look at PowerShell module GPODOC for example / shameless plug).
I’ve seen places that only use packages, or only use Task Sequences, or only use script wrapping, or only repackage with AdminStudio (or some alternative). That’s like doing every repair job in your house or apartment with a crowbar.
There’s nothing wrong with ANY means of deploying software as long as it’s the most efficient and reliable option for the situation. Just don’t knee-jerk into using one hammer for every nail, screw, and bolt you come across.
Pick the right tool or method for each situation/application. Doing everything “only” one way is ridiculously inefficient and time-wasting.
Sharing SQL Instances
The SQL licensing that comes with a System Center license does not permit hosting third-party products. Not even your own in-house projects, technically speaking. You “can” do it, but you’re not supposed to.
What that means is, when you run into a problem with the SQL Server side of things, and you call Microsoft, and they look at it and see you have added a bunch of unsupported things to it, you’ll likely get the polite scripted response, “Thank you for being a customer. You appear to be running in an unsupported configuration. Unfortunately, we can’t provide assistance unless you are running in a supported configuration. Please address this first and re-open your case, if needed, for us to help? Thank you. Have a nice day. Bye bye now.“
And, now, you’re facing an extended duration of what could have been a simple problem (or no problem at all, since your third-party app might be the problem).
Configuration Manager is extremely demanding of it’s SQL resources. Careful tuning and maintenance is VERY VERY VERY often the difference between a smooth-running site, and an absolute piece of shit site. I can’t stress that enough.
Leeching SQL Resources
Some 3rd party products, who I’m advised not to name for various legal reasons, provide “connection” services into the Configuration Manager database (or SMS provider). Attaching things to any system incurs a performance cost.
Before you consider installing a “trial” copy of one of those in your production environment, do it in a test environment first. Benchmark your environment before installing it, then again after. Pay particularly close attention to what controls that product provides over connection tuning (polling frequency, types of batch operations, etc.).
And, for God’s sake (if you’re an atheist, just replace that with whatever cheeseburger or vegan deity you prefer), if you did install some connected product, do some diagnostic checking to see what it’s really doing under the hood.
And just as important: if you let go of the trial (or didn’t renew a purchased license) – UNINSTALL that product and make sure it’s sticky little tentacles are also removed.
Make sure backups are configured and working properly. If you haven’t done a site restore/recovery before, or it’s been a while, try it out in an isolated test environment. Make sure you understand how it works, and how it behaves (duration, results, options, etc. )
Ignoring the Logs
Every single time I get a question from a customer or colleague about some “problem” or “issue” with anything ConfigMgr (or Windows/Office) related, I usually ask “what do the logs show?” I’d say, on average, that around 80% of the time, I get silence or “hold on, I’ll check”.
If you ask me for help with any Microsoft product or technology, the first thing I will do is ask questions. The second thing I will do is look at the appropriate logs (or the Windows Event Logs).
So, when the log says “unable to connect to <insert URL here>” and I read that, and try to connect to same URL and can’t, I will say “Looks like the site isn’t responding. Here’s my invoice for $40,000 and an Amazon gift card”. And then you say “but I could’ve done that for free?!” I will just smile, and hold out my greedy little hand.
Keep in mind that the server and client logs may change with new releases. New features often add new log files to look at.
Check the logs first.
Ignoring AD: Cleanups
Managers: “How accurate is Configuration Manager?”
Answer: “How clean is your environment?”
Managers: (confused look)
If you don’t have a process in place to insure your environment is maintained to remove invalid objects and data, any system that depends on that will also be inaccurate. It’s just a basic law of nature.
Step 1 – Clean up Active Directory. Remove accounts that no longer exist. Move unconfirmed accounts to a designated OU until verified or removed. This process is EASY to automate, by the way.
Step 2 – Adjust ConfigMgr discovery method settings to suit your environment. Don’t poll for changes every hour if things really only change monthly. And don’t poll once a month if things really changes weekly. You get the idea. Just don’t be stupid. Drink more coffee and think it through.
Step 3 – I don’t have a step 3, but the fact that you actually read to this point brings a tear to my eyes. Thank you!
Ignoring AD: Structural Changes
But wait – there’s more! Don’t forget to pay attention to these sneaky little turds:
Additions and changes to subnets, but forgetting to update Sites and Services
Changes to domain controllers, but not updating DNS, Sites and Services or DHCP
Changes to OUs, but forgetting to update GPO links
All the above + forgetting to adjust ConfigMgr discovery methods to suit.
Ignoring DNS and DHCP
“It’s never DNS!“, is really not that funny, because it’s very often DNS. Or the refusal to admit there might be a problem with DNS. For whatever reason, many admins treat DNS like it’s their child. If you suggest there might be something wrong with it, it’s like a teacher suggesting their child might be a brat, or stupid, or worse: a politician. The other source of weirdness is DHCP and its interaction with DNS.
Take some time to review your environment and see if you should make adjustments to DHCP lease durations, DNS scavenging, and so on. Sometimes a little tweak here and there (with CAREFUL planning) can clean things up and remove a lot of client issues as well.
Check DHCP lease settings and DNS scavenging to make sure they are closely aligned to how often clients move around the environment (physically). This is especially relevant with multi-building campus environments with wi-fi and roaming devices.
Task Sequence Repetition
A few releases back, Microsoft added child Task Sequence features to ConfigMgr. If you’re unaware of this, read on.
Basically, you can insert steps which call other Task Sequences. In Orchestrator or Azure Automation parlance this is very much like Runbooks calling other Runbooks. Why is this important? Because it allows you to refactor your task sequences to make things simpler and easier to manage.
Let’s say you have a dozen Task Sequences, and many (or all) of them contain identical steps, like bundles of applications, configuration tasks, or driver installations. And each time something needs updating, like a new application version, or a new device driver, you have to edit each Task Sequence where you “recall” it being used. Eventually, you’ll miss one.
That’s how 737 Max planes fall out of the sky.
At the very least, it’s time wasted which could be better spent on other things, like drinking, gambling and shooting guns at things.
Create a new Task Sequence for each redundant step (or group of steps) used in other Task Sequences. Then replace those chunks of goo with a link to the new “child” Task Sequence. Now you can easily update things in one place and be done with it. Easy. Efficient.
Last, but certainly not least is staffing. Typically, this refers to not having enough of it. In a few cases, it’s too many. If your organization expects you to cover Configuration Manager, and it’s SQL Server aspects, along with clients, deployments, imaging, updates, and configuration policies, AND maintain other systems or processes, it’s time for some discussion, or a new job.
If you are an IT manager, and allow your organization to end up with one person being critical to a critical business operation, that’s foolish. You are one drunk driver away from a massive problem.
An over-burdened employee won’t have time to create or maintain accurate documentation, so forget the crazy idea of finding a quick replacement and zero downtime.
In team situations, it’s important to encourage everyone to do their own learning, rather than depend on the lead “guru” all the time. This is another single point of failure situation you can avoid.
If there’s anyone who knows every single feature, process and quirk within Configuration Manager, I haven’t met them yet. I’ve been on calls with PFE’s and senior support folks and heard them say “Oh, I didn’t know that” at times. It doesn’t make sense to expect all of your knowledge to flow out of one person. Twitter, blogs, user groups, books, video tutorials, and more can help you gain a huge amount of awareness of features and best practices.
I purposely left out “OSD” in the title, because I see a significant increase in non-OSD tasks being performed with Task Sequences. This includes application deployments, complex configuration sequences, and so on. Whether those could be done more efficiently/effectively using other tools is a topic for another beer-infused, knife-slinging, baseball bat-swinging discussion. Just let me know early-on, so I can sneak out the back door.
Anyhow, this is just a short list of “tips” I find to be useful when it comes to planning, designing, building, testing, deploying and maintaining Task Sequences in a production environment. Why 7? Because it’s supposed to be lucky.
Are you sitting down? Good. This might be a big shock to you, but I am *not* the world’s foremost expert on Task Sequences, or Configuration Manager. And some (maybe all) of these “tips” may be eye-rolling old news to you. But hopefully, some of this will be helpful to you.
So often, I see someone jump in and start piling everything into a new Task Sequence at once, and THEN trying it out. This can make the troubleshooting process much more painful and time-consuming than it needs to be. Start with what developers call a “scaffold”, and gradually build on that.
I usually start with the primary task at hand: such as “install Windows 10 bare metal“, test that with only the absolute bare minimum steps required to get a successful deployment. Then add the next-most-important steps in layers and continue on.
However you decide to start, just be sure to test each change before adding the next. It might feel tedious and time-wasting, but it can save you 10 times the hassle later on.
Divide and Conquer
Don’t forget that the latest few builds of ConfigMgr (and MDT btw) support “child”, or nested, Task Sequences. In situations where you have multiple Task Sequences which share common steps, or groups of steps, consider pulling those out to a dedicated Task Sequence and link it where needed. Much MUCH easier to maintain when changes are needed.
Some common examples where this has been effective (there are many more I assure you) include Application Installations, Drivers, Conditional blocks of steps (group has a condition, which controls sub-level steps within it, etc.), and setup steps (detection steps with task sequence variable assignments at the very top of the sequence, etc.)
I’m also surprised how many people are not aware that you can open two Task Sequence editors at the same time, side-by-side, and copy/paste between them. No need to re-create things, when you can simply copy them.
Organize and Label
If you are going to have multiple phases for build/test/deploy for your Task Sequences, it may help to do one (or both) of the following:
Use console folders to organize them by phase (e.g. Dev, Test, Prod, and so on)
Use a consistent naming convention which clearly identifies the state of the Task Sequence (e.g. “… – Prod – 1.2”)
This is especially helpful with team environments where communications aren’t always optimal (multiple locations, language barriers, time zones, etc.)
Establish a policy and communicate it to everyone, then let the process manage itself. For example: “All you drunken idiots, listen up! From now on, only use Task Sequences with ‘Prod’ in the name, unless you know it’s for internal testing only! Any exceptions to this require you eating a can of bug spray.”
Wherever you can use a comment, description, or note, field in anything, you should. This applies to more than ConfigMgr as well. Group Policy Objects and GP settings are rife with not having any explanation about why the setting exists or who created it. Don’t let this mine field creep into your ConfigMgr environment too.
Shameless plug: For help with identifying GPOs and settings (including preferences) which do or don’t have comments, take a look at the GpoDoc PowerShell module, available in the PowerShell Gallery, and wherever crackheads can be found.
The examples below show some common places that seem to be left blank in many (most) organizations I run across.
Other places where documentation (comments) can be helpful are the “Scripts” items, especially the Approval comment box.
Side note: You can query the SQL database view vSMS_Scripts, and check the “Comment” column values to determine what approval comments have been added to each item (or not). Then use the “Approver” column values to identify who to terminate.
This is aimed at larger ConfigMgr teams. I’ve seen environments with a dozen “admins” working in the console, all with Full Administrator rights. If you can’t reign that wild-west show in a bit, at least sit down and agree who will maintain Task Sequences. Everyone else should stay out of them!
This is especially important if the team is not co-located. One customer I know was going through a merger (M&A) and, apparently, one group in another country, didn’t like some of the steps in their Windows 10 task sequence, so they deleted the steps. No notifications were sent. It was discovered when the first group started hearing about things missing from newly-imaged devices.
In that case, the things needed were (A) better communications between the two groups, and (B) proper security controls. After a few meetings it was agreed that the steps in question would get some condition tests to control where and when they were enabled.
Holy cow, do I see a lot of environments where the Backup site maintenance task isn’t enabled. That’s like walking into a biker bar wearing a “Bikers are all sissies!” t-shirt. You’re just asking for trouble.
Besides a (highly recommended) site backup, however, it often pays dividends to make what I call “tactical backups”. This includes such SUPER-BASIC things as:
Make a copy of your production task sequences (in the console) – This is often crucial for reverting a bunch of changes that somehow jacks-up your task sequence and you could spend hours/days figuring out which change caused it. Having a copy makes it really easy (and fast) to recover and avoid lengthy impact to production
Export your product task sequences – Whether this is part of a change management process (vaulting, etc.) or just as a CYA step, it can also make it easy to recover a broken Task Sequence quickly.
Either of these are usually much less painful than pulling from a site backup.
As a double-added precaution, I highly/strongly recommend that anytime you intend to make a change to a production task sequence, that you make a copy of it first. Then if your edits don’t work, instead of spending hours troubleshooting why a revert attempt isn’t actually reverting, you can *really* revert back to a working version.
Don’t Overdo It
One finally piece of advice is this: Just because you get comfortable using a particular hammer, don’t let this fool you into thinking everything is a nail. Task Sequences are great, and often incredibly useful, but they’re not always the optimal solution to ever challenge. Sometimes it’s best to stick with a very basic approach, like a Package, Application, or even a Script.
I’ve worked with customers who prefer to do *everything* via a Task Sequence. Even when it was obvious that it wasn’t necessary. The reason given was that it was what they were most familiar with at the time. They have since relaxed that default a bit, and saved themselves quite a bit of time. That said, Task Sequences are nice and should always be on your short list of options to solve a deployment need.
I hope this was helpful. If not, you can also print this out, and use it as a toilet bombing target. Just be sure to load up on a good Mexican lunch before you do. Cheers!
I’ve consumed way way waaaaay too much coffee and tea today. Great for getting things done, not great for my future health.
CMHealthCheck 1.0.8 is in the midst of being waterboarded, kicked, beaten, tasered and pepper-sprayed to make it squeal. I’m close to a final release. Among the changes in testing:
Packages, Applications, Task Sequences (just summary), Boot Images (summary), etc.
User and Device Collections
SQL Memory allocation (max/pct)
Fixed “Local Groups” bug
Fixed “Local Users” bug
Enhanced Logical Disks report
Fixed “Installed Software” sorting issue
Fixed “Services” sorting issue
Fixed null-reference issues with “Installed Hotfixes”
Still in the works:
Sorting issue with ConfigMgr Roles installation table
Local Group Members listing
More details for Discovery Methods
Enhancements to the HTML reporting features
Stay tuned for more.
Note: The current posted version (as of 3/8/19) is 1.0.7, which is what will install if you use Install-Module.
To load the 1.0.8 test branch, go to the GitHub repo, change the branch drop-down from “master” to 1.0.8 (or whatever the other name happens to be at the time) and then use the Download option to get the .ZIP file. Then extract to a folder, and use Import-Module to import the .psd1 file and start playing.
So… I needed a “quick” (easy/lazy) way to pull some common numbers from (almost) any ConfigMgr site, regardless of whether they’re on 2012 R2 up to 1809. It also has to work whether or not they have a RSP role available. In some cases, the SQL platform is locked up under DBA minefields, so SSMS isn’t always a given either. All I need is “read” access to the CM database, where it resides.
What are these “common numbers” of which I speak? Some examples…
Office 365 ProPlus installations
OneDrive sync client versions
For each, I needed 2 or 3 distinct variations, such as “Detailed”, “Total Counts” and “By Version”, etc.
The PowerShell script is pretty basic, so try to swallow your drink before you click on the download link (below).
It requires a sub-folder named “queries”, which you dump your .sql files into, like the samples shown below. But you can put the folder anywhere and use the -QPath parameter to point to the correct location. It reads in all .sql files and displays them in a gridview to select which to run.
The output options are “Grid” (default), “CSV” and “Pipeline”.
Grid – is the default, and just dumps the results into a Gridview panel
CSV – dumps the results to a CSV file with the same name as the selected SQL query (first gridview)
Pipeline – is the most powerful and sexy of the three amigos. You can use this to post-process however you like, and is intended for use with the “detailed” flavors of query results.
I chose to put the .SQL files in their own place to allow easier updating, improving, replacing, adding to, etc. So, the examples I linked above (and below) are only examples. You may want to use your own, or add to the mix, etc.
If it makes sense, I may make a PS module out of it and post it to PS Gallery. I’ll wait to see if there’s any interest/need for that first.
If you already know what CMHealthCheck is, then I’d like to say “thank you!”. If you are not aware of what it is, I’d like to say “thank you!” just for taking the time to read this far. Seriously, most people would have fallen asleep by, right, about….. here.
Still awake? Ok.
So 1.0.5 was published up to the PowerShell Gallery late last night or early this morning, it’s still too blurry for me. Rather than re-explain the entire thing, which you can read here, I’ll focus on “what’s new!”, which is the added function: Export-CMHealthCheckHTML
This new laxative-powered meth-infused function comes with the following sex toys (parameter options) to control how it works. Batteries not included…
ReportFolder – This is the folder path to where the output from Get-CMHealthCheck is found. If you ran that against some unsuspecting ConfigMgr site server while it was passed out drunk, it should have cranked out something like ..\2018-09-21\cm01.contoso.local or ..\2018-09-21\cm01.ipukedonyourdoglastnight.local or whatever
OutputFolder – This is the path where you wish to make the HTML report file magically appear with an imaginary puff of smoke and glitter stuff. The default is your user profile “Documents” folder. The filename is “cmhealthreport.htm” because I don’t really have much of an imagination and my coffee ran out.
Detailed – this is a “switch” that just say “Hey man, tell me all and I mean ALL of the ugly details about my site”, you get the idea.
CustomerName – You probably figured this out, but it was conceived with the assumption this function will be used by a consultant. So if you work for “DoucheBrain Corporation” then enter that or whatever.
AuthorName – Your name (assuming you don’t have people doing this for you while you lounge around on a yacht)
CopyrightName – Eh, whatever you want. The default is me.
HealthcheckFilename – don’t mess with this. the default works.
MessagesFilename – same as above
HealthcheckDebug – Use this if you want, or just -Verbose will work fine too.
Theme – This is where you can get stupid-fancy, whatever that means. There are three included styles: Default, Emerald, Ocean and Monochrome. Monochrome is boring. Ocean is kind of blue-ish. Emerald is green-ish, and there’s also “Custom“.
CssFilename – If you set Theme to “Custom” then this param is where you provide the CSS file path to use. The CSS file content is imported into the HTML output, rather than linked. Just because it felt right.
TableRowStyle – This allows you to apply some opiate-infused metaphysical coolness. The options are “Solid“, “Alternating” and “Dynamic“. When you use “Dynamic“, clap your hands together and say it like the prosecutor guy said “Identical” in My Cousin Vinnie. If you haven’t seen the movie, stop right here and watch it now. It’s that important. Seriously. I’m not kidding. I’ll wait… all good? Okay, so “Solid” just applies the styles without any fancy stuff. “Alternating” does on/off styles on even/odd table rows (like Word’s table style 4 group, only without any real imagination), and “Dynamic” adds super-cheap mouse-over styling to table rows, so you can play with the report for hours, and get nothing done.
ImageFile – Adds your super fantabulous increditastical logo image to the heading of the report. The default is the same cheezy CMHealthCheck logo I created in PowerPoint (shown above) with 4 cups of coffee and 1 hour of sleep. It’s okay, but you may want to insert your own logo to impress the boss. Just specify the path and filename. It will get smashed down to 100 x 100 pixels, just be aware.
OverWrite – I don’t think this param actually does anything, but I figured if you read this far, you might really care. I am honored. Seriously.
Well, the original version of this, which is still based heavily upon the incredible work of others like Raphael Perez, David O’Brien and probably others I’m forgetting, only provided a report via Microsoft Word. And as most admins would agree, it’s not very common to install Microsoft Word on a ConfigMgr site server. This means you have to generate the audit information on the site server, and then run the report publisher on a separate computer. Cumbersome.
This function makes it possible to generate a report “directly on” the ConfigMgr site server without having to make any additional changes to the server. And it looks kind of cool too.
How to Get it?
Open a PowerShell console on your ConfigMgr site server (CAS or Primary), which is on Windows Server 2012 R2 or later, with PowerShell 5.x or later, hopefully, using “Run as Administrator”
Accept the defaults (smack that “Y” key a few times, it’s okay)
How to Figure it out?
Type: Get-Module (press Enter)
Get-Command -Module CMHealthCheck
Get-Help Get-CMHealthCheck -Detailed
Inhale deeply, exhale slowly, avoid standing up too quickly
Drink your coffee or energy drink now
After you export the data, locate the output folder and confirm it has a bunch of .xml files in it.
Get-Help Export-CMHealthCheckHTML -Detailed
Same steps as above (inhale/exhale/drink/read)
Use the amazing examples to help guide you to the desired options to try. Try a few others and giggle out loud. Why not?
Open the cmhealthreport.htm file
Send me a note on what you think about it (Twitter is okay, GitHub Issues entry is better)
If you like it, and want to express support, Amazon gift cards are really nice, just saying. Or you can print out the source code, drop it in a toilet and decorate it too.
This entire mess of amateur writing was based on 1.0.5, so if you’re looking at a later version, please read the online documentation to see what may be new/different (or deprecated). And bonus note: Be careful not to use “depreciated” for “deprecated”, as they are very different words.
PS – I’m on travel next week, but not to Orlando unfortunately. My replies may be slow.
I meant to post this a few weeks ago, but anyhow… Microsoft released an updated ODT which removes the “Match Current OS” option from the language options list. That seems to work fine. However, the Project Online client has an issue with the Detection Rule being the same as Office 365 ProPlus. So the install (deployment) on a machine with O365 Pro Plus (latest/same version) causes the Project deployment to think it’s already installed. Just change the detection rule and it works. The Visio Pro deployment uses a different detection rule and seems to work fine.
As for Shared Computer Activation deployments, there are at least two (2) ways to go. One is supported, the other is unknown (at this point). The first is to simply build a new deployment, which sounds like a waste of storage space (compared with traditional O365 ProPlus deployment builds using ODT and XML files) but if you have deduplication turned on for the content source location it shouldn’t be a concern. The other (semi/un-supported) way is to manually copy the “configuration.xml” and make a Shared Activation flavor of it, then add a new deployment type, set some sort of condition to control the scope of that deployment type, and go that route. A little more convoluted, but possible.
While working with a customer to deploy Office 365 ProPlus, with SCCM 1806, we discovered a bug in the OCT that has been confirmed by Microsoft and hopefully fixed soon. The bug is related to the language selection “Match the Current OS” with respect to (English-US) platforms. That selection, for some reason, does not download the required language pack files for the deployment source, and causes the deployments to fail with an error that mentions “missing files”.
The catch here is it won’t return an error when it fails via SCCM. The deployment fails but still returns “success” (exit code 0), and writes the registry key which is shown in the Detection Method configuration. To see the error, we had to execute the setup.exe with /configure and the relevant .xml file from the client cache folder. This is actually two (2) “bugs” as far as I can tell.
The fix/workaround is to simply select the actual language (e.g. “English (United States)”) rather than use the default “Match the Current OS”.
Someone asked if that surgeon on the left is Johan. I cannot confirm, but it wouldn’t surprise me.
System Center Configuration Manager current branch 1807+
Basic knowledge about how to use ConfigMgr
Office 365 / ProPlus licensing
A really bad attitude
Create an Application and Deployment in ConfigMgr
Target a Collection (devices or users)
Punch someone in the face and go home (no, don’t do that)
During the process of building and deploying the Office configuration, the ConfigMgr console will be locked out from making changes. You can still make it visible, but no scrolling/selecting is allowed. Therefore, if you intend to deploy the configuration at the end of the procedure below, you should prepare the target collection in advance.
This will require access to the Internet in order to download the content for building the O365 deployment source. If you don’t have access to the internet, you may want to look for a new job.
I posted a summary version of this using ConfigMgr 1806 on another blog here. But this one has french fries.
Open the ConfigMgr admin console. This is important.
Navigate to Software Library > Office 365 Client Management
On the Office 365 Client Management dashboard, scroll over to the far right until you see that high-quality icon with “Office 365 Client Installer” caption. Click on it like you mean it. (Just kidding about the icon, it really is nice)
Give the Application a name (e.g. “Office 365 ProPlus with Visio and Project and Fries – 64-bit”)
Enter a Description (optional)
Enter the UNC source location path (the folder must exist, but the content will be populated at the end of this exercise). It must be a UNC path. Drive letters are for losers.
On the “Office Settings” page, click “Go to the Office Customization Tool” (or “Office Customisation Tool” for you non-American folks). NOTE: If you do not already have the latest version of OCT installed, it will prompt you to download and extract it somewhere. Then it will continue on. Otherwise, it will just continue on.
The OCT home page uses a layout designed by Stevie Wonder. It’s very spread out, so, on a low-res display, expect some finger exercise workouts on your mouse or trackpad. Anyhow, look for “To create or update a configuration file, click Next” and click on (you guessed it:) Next.
The Software and Languages page will open first.
Enter the Organization Name and select the Version (32 or 64 bit), then click Add. IMPORTANT: Pay attention to the ADD and UPDATE buttons throughout this exciting journey, there is a reward at the end. I’m just kidding, there is no reward, and no Santa Claus either. Note also that while you’re making selections and changes, the information is being updated along the right-most column of the OCT form.
Select the Software Suite or Product “Office 365 ProPlus” from the drop-down menu, and click Add
Select the drop-down again, and choose “Visio Pro for Office” and click Add again.
Select the drop-down again, and choose “Project Online Desktop Client” and click Add one more time.
The Software section on the right-hand settings column should show all three selections.
Scroll down to Languages. You HAVE to select an option here. It is not optional. The default choice for most situations will be “Match Operating System“, however, you can add more languages if you like, or just to have some fun with users by dropping unfamiliar languages on them.
Scroll back up so you can view the navigation menu at top-left again. Then select “Licensing and display settings”
For most situations, the KMS or MAK options will be disabled, with KMS automatically selected. If yours is different, who cares, I’m writing this crappy blog post, not you. So there.
Under “Additional Properties“, you can select options to enable Shared Computer Activation, Automatically accept the EULA, and Pin Icons to Taskbar. It’s worth noting that there is no longer a warning label about the taskbar icons, so it would appear to work on Windows 10.
There is no “Add” or “Update” button to click for this part, so calm down, we’re almost there.
Scroll up to the navigation menu again and select “Preferences“. This is where you may spend the rest of your life clicking on things, because there’s a lot to click on. Or you may choose to ignore all of it and instead blame configuration issues on whoever handles GPO and MDM settings. If that’s you, well, it sucks to be you. Choose wisely.
Take a moment to review your settings along the right-hand “Configured Settings” column. Take a moment also to reflect on your poor choices in life, those missed opportunities, that last vacation trip, and how dysfunctional your family is (or could be). Now, when you’re done with that, and put the loaded gun and liquor bottle back in the bottom drawer, and…
Click “Submit” at the very top right.
After you click Submit, you will be returned to the Application wizard. Click Next.
On the Deployment page, it will ask if you want to deploy the application now. If you have a target collection ready to go, you can go for it. YOLO.
If you choose Yes, you will be prompted for typical deployment configuration settings, otherwise, you’ll click Next two more times and then…
Wait for the content to download and the deployment source to be prepared.
Don’t forget to distribute the content to your DPs.
Don’t forget to populate the target collection.
Don’t forget to allow time for policy updates, etc.
You can also modify Office 365 Client Installations by using the “Import” feature at the top-right of the OCT form.
I’d ask for feedback/comments on this, but nobody ever posts feedback or comments.