Search This Blog

Showing posts with label IT Best Practices. Show all posts
Showing posts with label IT Best Practices. Show all posts

08 December, 2024

The Story of SCCM Collections: Bringing Order to the IT Workbench

The Story of SCCM Collections: Bringing Order to the IT Workbench

In a bustling mid-sized IT department, the workstation management team found themselves at the heart of every operation. These engineers were the unsung heroes, responsible for ensuring that every laptop, desktop, and server under their care ran smoothly. From deploying software updates to enforcing compliance policies, they were always at the ready. With hundreds of devices and users to manage, the team had long ago realized that managing such a sprawling ecosystem required precision, efficiency, and a toolset that could keep up. That toolset was Microsoft System Center Configuration Manager (SCCM), and at the core of SCCM’s functionality lay its powerful collections.

For this team, collections were more than just a way to organize devices and users—they were the backbone of effective IT management. With collections, the team could group devices and users based on specific criteria, enabling targeted deployments and precise oversight. Let’s delve into how the workstation engineers used SCCM collections to transform their operations, bringing order to their environment and mastering the art of IT management.

Collections: The Building Blocks of Targeted Management

One typical Monday morning, the team faced a challenge: the marketing department needed an urgent update to their design software. The request wasn’t unusual, but it underscored a larger truth about IT operations: not all deployments are created equal. The engineering team couldn’t just blanket the entire network with the update—it would wreak havoc on machines that didn’t need it. They needed to target only the devices used by the marketing department, and that’s where device collections came into play.

Device Collections: Where Machines Find Their Place

The team opened SCCM and navigated to Device Collections, their starting point for organizing endpoints. A device collection is SCCM’s way of grouping machines, and its flexibility allows IT teams to target them based on various attributes, such as location, operating system, or naming conventions.

The engineers began by creating a new collection called Marketing-Laptops. Naming conventions were critical—collections needed to be identifiable at a glance. The team had long established a practice of descriptive, department-based names to avoid confusion.

Instead of manually adding devices to the collection—a process they knew would quickly spiral out of control—they set up query-based membership rules. This allowed the collection to automatically include devices meeting specific criteria. For Marketing-Laptops, they used a straightforward WQL (Windows Query Language) query:

SELECT * FROM SMS_R_System WHERE DeviceName LIKE 'MKT-%' AND OperatingSystemNameAndVersion LIKE '%Windows 11%'

This query ensured that only devices with names starting with “MKT-” and running Windows 11 would be included. With the query in place, the collection populated itself in minutes. Now, any new laptop added to the marketing department would automatically become part of this collection, requiring no manual intervention.

With the devices grouped and ready, the team deployed the update. The targeted approach ensured that only the intended devices received the new software, reducing the risk of unintended disruptions.

User Collections: Making IT Personal

The next day, a new request arrived: deploy a compliance application to the legal department staff. This task wasn’t about machines—it was about the users themselves. The engineers turned to user collections, SCCM’s tool for organizing people.

First, they needed to define the membership of the collection. Instead of manually specifying users, they decided to integrate with Active Directory, the source of truth for user accounts and groups. Using a WQL query, they linked the collection to the Active Directory group Contoso\Legal:

SELECT * FROM SMS_R_User WHERE UserGroupName = 'Contoso\\Legal'

This approach ensured that the collection stayed dynamic. If someone joined or left the legal department, the collection would update automatically, reflecting the changes in Active Directory.

The team also made sure to test the deployment path before rolling it out. By creating a smaller test collection, they simulated the deployment process to ensure it worked as expected. Lessons from the past—like the time they accidentally sent beta software to executives—had made them meticulous about testing.

Keeping Collections Manageable

As the IT environment grew, so did the number of collections. Without proper management, collections could quickly become unmanageable, leading to confusion and inefficiency. The engineers adopted several best practices to keep their collections organized:

  • Folders for Organization: They grouped collections into folders based on departments, projects, and system types. This made it easy to find and manage specific collections without sifting through a long list.
  • Staggered Refresh Schedules: Dynamic collections refreshed at different intervals to avoid overloading the SCCM server. High-priority collections, like those for critical updates, refreshed frequently, while less dynamic collections, such as Retired-Devices, refreshed less often.
  • Clear Documentation: Every collection was documented in a shared spreadsheet, detailing its name, purpose, membership criteria, and deployment history. This not only helped current team members but also made onboarding new engineers much smoother.

Day-to-Day Operations: Where Collections Shine

With their collection strategies in place, the team found that SCCM became a powerful ally in their day-to-day operations. Patch Tuesday, once a chaotic scramble, was now a predictable and manageable process. By targeting collections based on operating system and patch level, they ensured that updates rolled out efficiently and with minimal disruption.

When new employees joined the company, onboarding was a breeze. Device and user collections worked together to ensure that each new hire received the necessary applications and settings within hours of logging in for the first time. Compliance audits, too, became less daunting. Collections provided clear, organized data on which machines and users were covered by specific policies.

The Collections Legacy

For the workstation engineering team, SCCM collections were more than just a feature—they were the foundation of a well-managed IT environment. By grouping devices and users based on specific, dynamic criteria, the team achieved precision in deployments and efficiency in operations.

SCCM collections weren’t flashy or attention-grabbing, but they were essential. They allowed the team to focus on solving problems and meeting business needs instead of drowning in manual tasks. In the world of IT, where chaos often looms just around the corner, collections provided structure, order, and a little peace of mind.

04 December, 2024

The Curious Case of the Incomplete SCCM Request

The Curious Case of the Incomplete SCCM Request

It was another Monday morning, and you’d barely settled into your chair when the email popped up: “Hey, can you automate the install of [Insert Application of the Week]? Thanks!”

Simple enough, right? Except experience told you that “simple” was a trap. Behind every “simple install” lurked unspoken dependencies, forgotten configurations, and that one obscure setting buried in a 200-page admin guide. This time, though, you were ready. You’d developed a system—a foolproof way to gather all the prerequisites and turn chaos into a smooth, automated masterpiece.

Here’s how you do it.

Start With a Gentle Interrogation

Your first move? Respond to the request with some polite but pointed questions. You’re not grilling a suspect—you’re just… clarifying.

  • What exactly do you want this to do?
    Is the goal to install the app and call it a day, or are there follow-ups like configurations, license activations, or mysterious registry keys?
  • What does “working” look like to you?
    Is it just sitting there quietly installed, or does it need to hum a specific tune on startup?
  • What could go wrong?
    If you’ve ever been told, “It works fine on the test machine,” you know this question is worth its weight in log files.

Asking the right questions upfront saves you from playing a game of “Who Broke It?” later.

Gather the Sacred Prerequisites

Every automation project has its holy relics—those bits of information and tools you must collect before starting your quest.

  1. The Installer
    Is it an MSI, an EXE, or something rarer, like a proprietary installer with no silent mode (cue dramatic sigh)? If it's an MSI, confirm the silent install switches (/quiet /norestart) and any custom properties.

  2. Dependencies
    Does this app need .NET, Java, or the collective hopes and dreams of the IT department? Make a list. Don’t forget drivers, libraries, or network permissions.

  3. Configuration Settings
    Are there configuration files to edit? Registry keys to add? Licensing servers to point to? Clarify if these need to be machine-wide or user-specific.

  4. Testing Criteria
    How will you verify the installation? Write a script or a test plan. Even a basic "open the app and poke at it" plan is better than crossing your fingers.

  5. Rollback Plan
    No one likes to think about failure, but it’s better to plan for it than to discover mid-install that your only rollback strategy is "unplug the computer and pray."

Beyond MSI: Tackling Configurations

Let’s say the install is only part of the job. Maybe the app needs some post-install TLC:

  • Configuration Files: You can automate edits to .INI, .JSON, or XML files with PowerShell.
  • Registry Keys: A little Set-ItemProperty action in PowerShell works wonders.
  • Service Connections: Does the app need to talk to a server or database? If yes, automate the setup and test the connection.

The key here is modularity. Each step should work on its own, like a Lego block. If the post-install fails, the install itself should remain intact.

The Magic of Application Groups

Now, what if you need to install not one but several applications, each with its quirks and dependencies? Enter SCCM application groups, the Swiss Army knife of multi-app deployments.

With application groups, you can:

  • Maintain Order: Specify the install sequence to avoid, say, installing the app before its dependencies.
  • Keep It Modular: Each application can have its detection methods and install/uninstall scripts.
  • Make Updates Easy: Need to tweak one component? No problem—you can update it without redoing the whole group.

For example, automating a developer workstation setup might include:

  1. Installing Visual Studio.
  2. Configuring Git.
  3. Setting up Node.js.
  4. Running a custom PowerShell script to pull environment settings.

Each step is managed individually but deployed as a seamless package. Efficiency and control? Check and check.

The PowerShell Angle

PowerShell is your best friend here. Let’s break it down:

  1. Pre-Checks: Before you do anything, make sure the system is ready. Check for disk space, existing dependencies, or incompatible versions.

    if ((Get-Volume -DriveLetter C).SizeRemaining -lt 10GB) { Write-Error "Not enough disk space!" exit }
  2. Silent Installation: Automate the install with Start-Process or SCCM cmdlets.

    Start-Process "msiexec.exe" -ArgumentList "/i MyApp.msi /quiet /norestart" -Wait
  3. Post-Install Tasks: Add configurations, apply registry keys, or start services.

    Set-ItemProperty -Path "HKLM:\Software\MyApp" -Name "ConfigKey" -Value "ConfigValue"
  4. Validation: Always test. Whether it’s as simple as checking for a file or as complex as running a test script, make sure you verify success.

The Final Word

Automation isn’t just about making life easier (though it definitely does that). It’s about creating robust, repeatable processes that reduce errors and free you to tackle more exciting challenges. By asking the right questions, gathering prerequisites, and embracing tools like PowerShell and SCCM application groups, you’ll deliver solutions that go beyond "just works" to "works beautifully."

And the next time someone asks for a “simple install,” you’ll smile, knowing you’re already three steps ahead.

03 December, 2024

The Unsung Heroes of Application Security: Managed and Group Managed Service Accounts

The Unsung Heroes of Application Security: Managed and Group Managed Service Accounts

Imagine a world where every application, every service, and every scheduled task in your environment needs its own username and password. Now imagine that every password is either forgotten, reused, or stored in a spreadsheet named “passwords_final_FINAL_v2.xlsx.” It’s not just frustrating; it’s a recipe for disaster. This is where Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) come in.

These accounts don’t demand glory or applause, but they do the unglamorous work of keeping your services running securely and efficiently. They are the ultimate "set it and forget it" solution for managing credentials in Active Directory environments. In this article, we’ll explore what MSAs and gMSAs are, why you should use them, how they compare to traditional service accounts, and how to implement them effectively.

What Are MSAs and gMSAs?

MSAs and gMSAs are special types of Active Directory accounts designed specifically to manage credentials for services, scheduled tasks, and applications. They are the answer to the problems caused by traditional service accounts, like forgotten passwords and over-permissioned accounts.

Managed Service Accounts (MSAs) were introduced in Windows Server 2008 R2 and are intended for use on a single computer. Think of them as a personal assistant for a server, managing its credentials and ensuring the server never forgets a password.

Group Managed Service Accounts (gMSAs), introduced in Windows Server 2012, take this concept to the next level. They allow a group of systems to securely share the same account, making them ideal for distributed applications, clusters, and services that span multiple machines.

MSAs and gMSAs have two key superpowers:

  1. Automatic Password Management: They handle password complexity and rotation, so you don’t have to.
  2. Kerberos Authentication: They integrate seamlessly with Active Directory’s security features, ensuring strong, reliable authentication.

Why Should You Use MSAs or gMSAs?

Applications often need credentials to perform their tasks—whether connecting to a database, calling an API, or running background jobs. Traditionally, we’ve relied on standard user accounts for this. But let’s face it: traditional service accounts are clunky and risky.

MSAs and gMSAs solve these problems by automating password management and locking down permissions. For example, a gMSA can rotate its password every 30 days (or on whatever schedule you prefer) without anyone lifting a finger. It ensures passwords are long, complex, and stored securely in Active Directory, where even the sneakiest hacker can’t easily access them.

And they’re not just secure—they’re convenient. Once set up, they require little to no maintenance. No more scrambling to update expired passwords or dealing with services crashing in the middle of the night because someone forgot to update a credential.

The Downsides of Standard Service Accounts

The standard service account—a repurposed user account with a static password—is the duct tape of IT. It gets the job done, but it’s far from ideal. Passwords need to be updated manually, which means they often aren’t. When they are updated, it’s a tedious, error-prone process that risks breaking applications. Worse, these accounts often have more permissions than they actually need, making them a prime target for attackers.

Using a traditional account might seem like the easy route, but it’s really just kicking the can down the road. The costs—both in time and security risks—tend to pile up over time.

MSAs and gMSAs vs. Standard Accounts: The Real-World Comparison

Let’s break this down with a simple scenario: You’ve deployed an application that needs to connect to a database. With a standard service account, you create a user in Active Directory, set a password, and configure the application to use it. Six months later, the password expires, and suddenly your app stops working. Users can’t log in, and you’re scrambling to reset the password and update every place it’s used.

Now, consider the same scenario with a gMSA. You create the account, configure it in your application, and forget about it. The gMSA takes care of everything: complex password rotations, secure storage, and seamless integration with Active Directory. Your app keeps running, and you can enjoy a good night’s sleep.

MSAs and gMSAs also shine in distributed environments. A gMSA can securely share credentials among multiple servers, allowing applications to communicate across nodes without exposing sensitive information.

When Should You Use MSAs or gMSAs?

  • Use MSAs for services or applications running on a single server, such as IIS or a scheduled task.
  • Use gMSAs for distributed applications, load-balanced services, or clusters that need to share credentials across systems.

If your environment runs on Active Directory and you’re not using MSAs or gMSAs, you’re leaving security and efficiency on the table.

Implementing MSAs and gMSAs

Setting up MSAs and gMSAs might sound intimidating, but it’s easier than you think. Here’s a quick guide to get started:

  1. Ensure the Active Directory PowerShell Module Is Installed

  2. Check Your Domain Functional Level:

    • MSAs require at least Windows Server 2008 R2.
    • gMSAs require Windows Server 2012 or higher.
    • Verify this by running:
      (Get-ADDomain).DomainMode
  3. To check if the KDS Root Key exists:

    Run the following command in PowerShell on a domain controller:

    Get-KdsRootKey

    If none Create a KDS Root Key for gMSAs:

    gMSAs need the Key Distribution Service (KDS) to generate and distribute passwords. Create the KDS Root Key with:

    Add-KdsRootKey -EffectiveImmediately
  4. Create the Account: For an MSA:

    New-ADServiceAccount -Name MyMSA

    For a gMSA:

    New-ADServiceAccount -Name MyGMSA -PrincipalsAllowedToRetrieveManagedPassword GroupName
  5. Install the Account on Target Servers: Install the MSA or gMSA on each server where it’s needed:

    Install-ADServiceAccount -Identity MyMSA
  6. Test the Account: Confirm it’s working:

    Test-ADServiceAccount -Identity MyMSA
  7. Remove When no longer needed

    Remove-ADServiceAccount -Identity MyMSA

Wrapping It Up

MSAs and gMSAs aren’t just another feature of Active Directory; they’re a game-changer for managing credentials securely and efficiently. By automating password management and integrating tightly with AD, they reduce risk and free up your time for more important tasks—like building great applications. Sure, they take a little effort to set up, but once they’re in place, they’re the IT equivalent of “set it and forget it.”

In a world full of password spreadsheets and service account headaches, MSAs and gMSAs are the quiet heroes we didn’t know we needed.

Resources