The Most Basic of Basics

Some of the less-common issues I’ve run across in the past few months on the road.  They all tie back to being careful to read the documentation and following the guidelines properly.  These are all 100% true.  This is a stream-of-semi-conciousness post, so it’s going to ramble a bit.

  • Client Push Installation Not Working
    • Client Push Installation Accounts weren’t configured to use the appropriate accounts or the accounts didn’t have permissions
    • AntiVirus was waiting around the corner to stab the client installation files in the neck and steal it’s lunch (exclusions)
  • Clients Not Functioning
    • Site Boundaries were missing
    • DNS is fucked worse than a construction site toilet
    • DHCP is waiting outside the construction site toilet after having eaten 15 burritos and a Coke
    • Network team hates the AD team who hates the SCCM team
    • AD team refuses to hear any complaints about their “perfect” DNS environment
    • Boundary Group systems weren’t configured properly
  • OSD deployments not working
    • Didn’t visit DeploymentResearch.com or any other pertinent web sites / blogs / conferences / book stores / random homeless people wearing a “OSD is cool AF” t-shirt / etc.
    • Didn’t watch any YouTube videos of Johan or Mikael, or anyone else that does this every day
    • Didn’t install the correct ADK version
  • PXE not working
    • PXE wasn’t actually installed
    • DHCP options AND IP Helpers were in conflict (should only use IP helpers)
    • Forgot to distribute boot images where needed
    • Forgot to come to work awake
  • Backups Not Working
    • Backup targets were moved without telling anyone
    • GPO settings were stopping the backup service
    • Backup target was out of space
  • SQL database connectivity issues
    • DBA team moved the database without telling the SCCM admins
    • SCCM admins urinated on DBA cars in the parking lot
    • Unsupported SQL configuration (with regards to SCCM)
  • Slow console and slow inventory and status processing
    • Database was more fragmented than the teeth of an old English town drunk
    • DBA’s never heard of Ola Hallengren or Steve Thompson
    • DBA’s heard more than they wanted from me about Ola Hallengren and Steve Thompson
  • Apps and Updates not deploying
    • Maintenance windows were set to impossible periods of availability
    • Collections were not properly aligned with maintenance windows
    • Collections were not named to clarify the use (and configuration) of maintenance windows
  • Couldn’t use “Run Scripts” feature
    • Forgot to check the “pre-release” features option (earlier builds)
    • Forgot to check the ‘Run Scripts’ feature / enable it (earlier builds)
    • Forgot to uncheck the “Script authors require additional script approver” option
    • Forgot to approve the scripts
    • Forgot to actually import any scripts (they thought it made its own with hot water and a spoon)
    • Forgot to upgrade site from 1702
  • Software Center not working / Apps not showing up
    • Using a GPO to place a shortcut to Software Center but referring to the wrong SCClient.exe
    • Nothing was actually deployed to the device or the user trying to use it
  • Software Updates not working
    • WSUS is hosed
    • WSUS is still hosed
    • IIS is hosed too, but over-hosed by WSUS at the moment
    • Never learned to read logs like WCM.log, WSUSCtrl.log, wsyncmgr.log, SUPSetup.log
    • Never bothers looking at any logs
    • Forgot to actually make groups and packages and deploy them to anything
    • Still using GPO settings that conflict with ConfigMgr policies
  • Slow Deployments
    • Poor boundaries and boundary groups
    • Poor poor poor boundary groups
    • Sad little boundary groups, all neglected and lonely
    • BranchCache? WTF is that?
    • Our Network guys are throttling my shit all the time and don’t need to?! What?
  • Too many admins logging into the site server all day / every day
    • No local console installations
    • No understanding of RBA configurations (where needed)
  • More coffee, back to work
Advertisements

This Week in Nerdy Stuff

While I’m still sorting out some personal issues and trying to grasp how it is so many American-English words that begin with “con” or “pro” or “in” don’t have corollary words that make any damned sense whatsoever, and still lamenting walking away from a trip to MMS/MOA this year to start a new job, well, here’s what flew past my dust-covered radar this week, and might have missed your smartphone as well.

A Hammer to Turn Screws

20161120_160743

Script: Check-Readiness.ps1

Purpose: Keeps me busy and away from drinking too much coffee.  Okay, seriously, it’s just another flavor of “check for Windows 10 upgrade readiness using PowerShell”. It can be used within SCCM or while standing naked in a WalMart, your choice.

<#
.DESCRIPTION
.PARAMETER SourcePath
Why didn't they use PARAMETRE, hmm? So American. Anyhow, SourcePath is wherever the Windows 10 media is located.
.PARAMETER OutputPath
If not "" then it will dump a file named <computer>-<result>.txt in that location.
.NOTES
I was only half awake when I wrote this. Use at your own risk.
#>
[CmdletBinding()]
param (
    [parameter(Mandatory=$True, HelpMessage="Path to setup.exe")]
    [ValidateNotNullOrEmpty()]
    [string] $SourcePath,
    [parameter(Mandatory=$False, HelpMessage="Path to dump output data")]
    [string] $OutputPath = ""
)
$setup = Join-Path -Path $SourcePath -ChildPath "setup.exe"
Write-Verbose "setup source is $setup"
if (!(Test-Path $setup)) {Write-Error "$setup not found"; break}
Write-Verbose "starting assessment"
$p = Start-Process -FilePath $setup -Wait -ArgumentList "/Auto Upgrade /Quiet /NoReboot /Compat ScanOnly" -PassThru
Write-Verbose "exit code: $($p.ExitCode)"
switch ($p.ExitCode) {
    -1047526896 { $result = "UpgradeReady"; break } 
    -1047526912 { $result = "SysReqtsFault"; break } 
    -1047526904 { $result = "CompatIssues"; break } 
    -1047526898 { $result = "InsuffDiskSpace"; break } 
    default { $result = "InvalidProductSku"; break }
}
if ($OutputPath -ne "") { 
    $filename = "$($env:COMPUTERNAME)-$result.txt"
    $filepath = Join-Path -Path $OutputPath -ChildPath $filename 
    $result | Out-File -FilePath $filepath -Append -NoClobber -Encoding Default
}
Write-Output $result

Shove it out as a Package, or make it a Script object you can spray all over helpless devices via Run Script.  Or run it directly (just add hot water and PSRemoting), or print it out, hang it on the wall, and laugh hysterically at it.  No matter what, it beats whatever your next staff meeting has to offer.

Cheers!

Dr. Skatterbrainz Answers Reader Mail

Warning: The following text may contain adult-ish offensive language which may cause unwanted side effects.  Read at your own risk.

“I was just wondering what you think about going into IT consulting for someone who’s never done it before, but who’s been working in IT direct for about ten years?” – Brad

It’s not for everyone, but some really enjoy it.  It also depends on whether you’re working from home/remote or on-site mostly.  If you’re used to being in a room full of people and a bustling office environment, then switch to being alone all the time, even with online communication tools, it’s sometimes lonely.  If you have pets or someone at home to talk to it helps, otherwise you should get outside frequently and mix with other people.  Coffee shop, park, etc.  It also requires you to impose your own control over scheduling, sleep, eating, exercise, etc.

If you prefer keeping hands-on with things after you build them, it might be tough letting go of each project and moving on to the next.  If you like having a steady office environment, that too may be a tough adjustment.  If you don’t like traveling a lot, or meeting strangers and getting used to strange places, accents, rules, customs, and so on, it may be a tough adjustment.

Other things to consider are how well you adjust to working alone, or with different teams from one day/week/month to the next, as opposed to being with the same group of people for months/years.

I would suggest that if you’re really curious/interested in consulting to give it a try.  You will be exposed to more variety and more ideas than you typically get with a steady office role.  But, no matter how it turns out, it will still be more experience, and more experience is good no matter what (as long as it doesn’t kill you or leave you brain-damaged). And you may get to rack up lots of flyer miles and hotel rewards points.

“Why do CIOs so often turn down requests from their own IT staff to improve tools and processes?” – Jim

Because most technical people suck at communicating things in terms of money.  Remember that old book “Women are from Venus. Men are from Mars”?.  CxO’s like numbers and charts.  The more colors and spiffiness (I made that term up) the better.  The situations where I’ve seen (or done by myself) a proposal laid out in terms of what it will provide in terms of the following, it got a positive result:

  • Cost savings
  • New revenue (not always welcome, unless it’s in a core competency)
  • Added capability (e.g. competitive advantage)

Any idea you have to improve things needs to be distilled down to what “improve” really means.  Improves what?  How?  For whom?  Keep walking that question back until it comes to a dollar figure.  And one other aspect I find that helps is to focus more on the repeat financial benefit, rather than a one-time benefit.  A simple one-time cost-savings doesn’t usually get them excited enough to set down the Martini and whip out the credit card, but a pay-off that keeps getting better every quarter/year is hard to ignore.  In the end, if you have to fluff the numbers to make it work, you need to ask yourself if you really have the best idea.  If it really makes sense you shouldn’t need to oversell it, but make sure you present it in the language the suit-clad folks really love to hear.

“Some of my siblings and cousins have a condescending view of the IT profession.  They’re all lawyers and marketing people, but somehow think IT is like dishwashing.  What’s the best thing I can do for that?” – Charles

Hi Charles.  I can completely sympathize.  I have a few of those people in my family as well.  You can either hold a grudge, or let it go. I prefer to let it go.  Time is your most valuable asset.  Don’t waste it.  The time you would spend on debating them could be better used on learning new skills or finding more projects to grow your experience.  Changing someone’s mind about things is almost impossible without proper firearms and pharmaceuticals.

“I’ve seen you pick on Microsoft Access a few times.  What do you hate about it?” – Chris

I don’t hate Access itself.  It’s a great product, especially for small scale needs.  But it’s not built for large-scale, shared use, and it couples the application (forms, reports, logic) with the data (tables, views, etc.) which doesn’t scale or lend itself to flexible maintenance.  It’s also very dependent on the version of Office installed, so upgrading the rest of Office then becomes hostage to it.

The other issue is that shared-use problems often lead to proliferation of multiple, standalone copies throughout the enterprise.  Maintaining consistency and centralized reporting becomes increasingly difficult.

Then when IT wants (or needs) to roll out a new version of Office, it turns into “Now hold on a minute!  That’ll break our precious Access DB ‘application’!”   The longer the Access app remains in production, the more intrinsic it becomes to business operations, making it more sensitive to disruption.  And the longer is remains in production, the more likely staff will have quit/retired/died/joined a cult, whatever, and now nobody is left who knows how to maintain or modify the code.

This often leads to the following discussion playbook scenarios, complete with the eye-rolling, mumbling, and drooling package…

Version 1

IT: “You guys in Finance need to upgrade this Access thing of yours so it works with 2016!”

Finance guys: “The guy who wrote it left months/years ago and we don’t have anyone who can update it”

IT: “Not our problem. Make it happen.”

Finance guys: “Then fuck you.”

Version 2

IT: “You guys in Finance need to upgrade this Access thing of yours so it works with 2016!”

Finance guys: “Okay, but since this is YOUR requirement, then IT should pay for all that work.”

IT: “No!”

Finance guys: “Then fuck you.”

Version 3

IT: “You guys in Finance need to upgrade this Access thing of yours so it works with 2016!”

Finance guys: “Okay, but we don’t have anyone who can do it due to schedules and other work.  Can IT do it for us?”

IT: “No!”

Finance guys: “Then fuck you.”

Version 4

IT: “You guys in Finance need to…”

Finance guys: “Just fuck you.”

Then we break for lunch, listen to IT complain about how <insert department name here> are a bunch of a-holes to work with.  We come back to the office, fighting off the carb-coma sleep monster, and repeat the same discussions again.  Someone will suggest the usual workarounds…

  • “Let’s install the Access runtime for 2007 or 2010 along with Access 2016!”
    • “Adding more complexity to our environment is not the answer.”
  • “Move it to Citrix or RDS!”
    • Citrix/RDS guy: “No!  I need funding to buy more hardware.”
  • “Let’s App-V or ThinApp it!”
    • “Carl – Do YOU know how to sequence that?”
      • “Ummm no.  But I hear it’s really cool.”
    • “You thought Justin Bieber was cool.”
      • “What’s wrong with Justin?!”
    • (continues on until some smacks the table to break it up)
  • “Let’s rent an unmarked van and kidnap that old guy that wrote this!”
    • “I have $53 on me.  Can we rent one that cheap?”
      • “I have duct tape, maybe a gift card too, hold on…”

In the end, the most expensive, least efficient and most painful “solution” will be chosen and everyone will be unhappy.  After a few months they will have left for other jobs and a new staff will be looking at it, wash rinse and repeat.  Or, in some cases, they hire someone to rewrite the app using modern tools that support shared use, are easy to maintain and even move to the cloud.

“I’d like to use Chocolatey at my company, but management won’t allow it and won’t pay for the business version.  Can I still leverage pieces of it somehow?” – Larry

There are several things you can “leverage” without using the public repository, or buying the business license features.

  • Set up an internal repository.  If there’s no objection to internal sourcing of packages.
  • Crack open Chocolatey packages for the silent installation and configuration syntax to use elsewhere.  Scripts, SCCM, etc.
  • Apply for a new job elsewhere.

Option 1 – Setting up an internal repo…

  1. Read this – https://chocolatey.org/docs/how-to-host-feed
  2. Test, test, and test some more
  3. Pilot deployment
  4. Production domination and ultimate anihilation

Option 2 – Cracking open a warm one…

  1. Locate the desired package (e.g. Microsoft Teams desktop app)
  2. Click on the “Package source” link along the left (opens the Github repo)
  3. Inspect the .nuspec file for some general details
  4. Inspect the xxxinstall.ps1 file for the code and tasty stuff
  5. Copy / adapt when you can into whatever else you’re using

Notes:

  • If you intend to “keep up” with the latest releases of a given package, you may need to repeat the above steps, or monitor the vendor source location(s) to react as they post new versions.
  • If you want to expand on this, you can post your own packages with internal modification requirements (icacls, registry hacks, etc.) as needed, or adapt them into your own deployment scripts or task sequences.

Cheers!

Send more questions via Twitter DM.  If you follow me, and your account doesn’t smell like a bot, or a weird cats-for-kids black market thing, then I will usually follow you back.

Great Moments in Obscure History: 1990

On this date, in 1990, a young man named Dave was working for an engineering firm in a small brick building buried somewhere in the southern United States.  His team was a merry group, who passed the time with an assortment of tasteless politically-incorrect humor and pranks.  It was on this date that one team member, Kevin, chose a random meme for the evening’s humor pool:  Convert real movie titles into porn movie titles.  Titles were selected at random for each person.

Mine was “Fist of Fear, Touch of Death” starring Bruce Lee.

I immediately responded with “Touch of Fear, Fisted to Death“.  Upon speaking these words out loud, I laughed so hard that I pulled a muscle in my left rib cage and had trouble breathing for a full day.

And that was Great Moments in Obscure History.

Windows 10 Migrations, SCCM Admin Staffing, and the 1990’s are Still Calling

I’m back home after a few weeks of on/off travel and finally have time to unwind.  Like the last week, the others were focused on Windows 7-to-Windows 10 migration planning and piloting work with either MDT or Configuration Manager (SCCM).  After getting fisted that many times, oops, I mean, exposed to the internal workings of various customer environments, I often need some time and distance to put it all into an objective perspective.  And that rhymes, so that’s cool too.

Windows 10 Migrations

Thankfully, most of the customers I deal with have a clue.  And if they don’t have all of the questions figured out, they’re at least eager to get answers, either on their own, or by asking around.  That’s always a good thing.  Some however, seem to be content with status quo.

I’ve said it before, and I will say it again:  Stop spending time shoe-horning Windows 10 into another Windows 7.  The same old “new car” metaphor comes to mind:  How would you feel if you went to buy a brand-new vehicle, and the sales person said to you “Your new car will be ready by tomorrow, we need to remove all of the new features so it works just like your 5 year old model.  We figured you couldn’t handle the new features“.  Pardon my Brooklynese, but you’d probably bitch-slap them with a set of brass knuckles.  At the very least, you’d spray them with the coffee in your mouth, and then proceed to another dealership for a better experience.

Your new car will be ready by tomorrow, we need to remove all of the new features so it works just like your 5 year old model.  We figured you couldn’t handle the new features.

So, why would you do the same with “TECHNOLOGY”?  You are handling THE EPITOME of “TECHNOLOGY”, not a vehicle, toothbrush or coffee machine (okay, maybe a coffee machine is more awesome, but stick with me here).  I realize this situation is almost always a cultural one.  As in, business culture.  Years and years of communication degradation and sneering looks while roaming the hallways, between IT and “users”, needs to end.  Time for an olive branch, or a box of doughnuts, or a box of doughnuts infused with Xanax or something.  Anything to stop the old and start the new.  And here’s why:

Settling the passive-aggressive cold war solves multiple problems at once.  First, it paves the way for cooperation, which helps greatly with current and future projects and implementing change in the environment.  Second, it helps OFFLOAD work done by IT into the hands of users.  That’s right, you can offload work into the hands of users.  Repeat that last sentence until your mouth gets dry.  For example, SCCM “Software Center”.  Learn it.  Know it.  Live it.  Use it.  Third, educating users on new features feeds reasons 1 and 2 and helps them find things on their own.  You consider users too stupid?  Okay, find the smartest users in each group and empower them as field reps for your initiatives.

Spending hours and hours shoving shortcuts into specific places using scripts and Group Policy?  Stop!  Show users how to find their own shortcuts and use the “pin” feature.  Sell this as “IT isn’t going to control your desktop world anymore.  We’re giving you FREEDOM and SUPPORT.”  EVERY single place I’ve seen this attempted, it has done wonders.  I believe in it whole-heartedly.

SCCM Admin Staffing

This is ancillary to the above rant, but relevant.  More relevant than the discussions involving MDT at least.  What am I talking about?  I’m talking about customers who either decided on their own, or were mislead by overzealous sales people, on the realistic demands required of people who manage SCCM in a production environment.  There are several factors to consider which impact the amount of time this product demands:

  • The scale/size of the environment (including geographic spread)
  • The existing staffing resources (who, where, how many)
  • The types of assets being managed
  • The specific features to be enabled and leveraged in SCCM
  • The abilities of the people who will manage SCCM

I’m sure there’s a quantifiable method to derive meaningful numbers, but allegory seems to be nearly as effective:

  • Customer A has 5,000 Windows devices spread across 20 locations in 5 countries, with an IT staff of around 6 people.
    • There are 24 distinct hardware models in production
    • On average 2 new models are introduced per year
    • Customer A wishes to implement SCCM for imaging, app deployments, software updates, inventory and reporting and endpoint protection
  • Customer B has 5,000 Windows devices located in 2 locations in the same geographic area, with an IT staff of 2.
    • There are 24 distinct hardware models in production
    • On average 2 new models are introduced per year
    • Customer B wishes to implement SCCM for imaging, app deployments, software updates, inventory and reporting and endpoint protection

Guess which one isn’t going to enjoy coming to work much longer?

Dear managers: STOP TRYING TO BE CHEAP.  Staff your environment like you really want it to be effective.  If you plan to do imaging, and it doesn’t really matter what you intend to use, Acronis, Ghost, or any other shitty outdated trash you like rather than MDT or SCCM, you need to dedicate staff to that role.  Keeping up with drivers, firmware and software, all the glue-sniffing InfoSec stupidity (that should be managed in the environment, not entirely in the image), the Change Control meetings (you do have CC in place, right?), and the subsequent pilot and rollout work, is not something to be expected of anyone devoting 1 hour a week to it.  If you don’t have someone to assign to the role, hire someone.

This also applies to other time-suck roles like software updates, application deployments and reporting.  In some environments, when there are dedicated “business reporting” roles, and they learn about someone having access to pull reports from asset inventory data, they will converge on that person like refugees surrounding a relief truck in a war zone.  If  any of this applies to your environment, and you haven’t already, sit down with your admin folks and ask questions.  Try to learn what the role actually entails.  How much time they typically spend on each part of their job and what could be done to reduce the time.  Maybe you already have the tools to deal with it and just need some training or guidance.  Maybe you need to look for newer/better/different tools.  Regardless, do something.  Don’t sit back and wait for it to automate itself, because that’s not going to happen.

I think I digressed a bit.

The 1990’s

If you’re still writing Kix, Batch or VBScript scripts to semi-automate your chores, why?

Is it because you’re still running them on outdated platforms?  Why?

Is it because “management” won’t approve updates to the platform environment?  Why?

Is it because “management” is afraid of change?  Why?

I’ll just say this:  The longer you continue to focus your attention and efforts on outdated shit, it only reinforces two things:

  • It further suppresses your skill set, and your marketability for applying for other jobs
  • It saves your employer money at the risk of increasing security vulnerabilities and reduced support options from vendors

If your goal is only to stockpile cash from your ridiculously high-paying job, so you can parachute out into something else, fine.  If you’re living paycheck-to-paycheck: get out!

Final thoughts:  The conveyor belt of technology change is not slowing down.  In fact it is speeding up.  Ask anyone who works with cloud services how often their tools are being updated (weekly).  Ask how often things like Windows and SCCM are being updated (monthly).  None of that was even conceivable 5 years ago.  The time to dump all the 10-year old practices isn’t now, it was a year ago.  Get moving!