Portal Kombat

Posted on Updated on

As Microsoft has integrated previously independent products evolved into a massive cloud service provider, disparate access methods and portals developed by individual product teams has lead to a an overwhelming number of different ways of accessing your MS cloud services. Examples include Office365, Azure AD, Dynamics, OMS, Intune and of course Azure.

While I applaud Microsoft’s movement to simplified, streamlined and unified portals where they make sense, it has been a bumpy ride. Up until earlier this year both Azure and Intune had two portals for a period. If that’s not confusing enough, not all functions are/were available in both portals. Some features are/were only available in the classic portal while others are/were only available in the modern portal.

To make it even more difficult for administrators, because of the Silverlight dependency, the classic portal does not support all modern browsers.

Here’s an article that outlines the browser support for each portal.

Let’s focus on Intune for now. Until the Windows 7 End of Life in January 2020 Microsoft will need to continue to support the classic Silverlight based portal to continue to provide support for Windows 7 devices that rely on agent based management. As organization move away from Windows 7 no agent required as OMA-DM is baked into Windows 10 the Azure service based version of the Intune portal can be used exclusively.

Figure 1- Classic Silverlight based Intune Portal

Figure 2- Azure “Ibiza” Portal

License Management

It’s hard to believe that something as simple (and revenue generating for Microsoft) like license assignment can be confusing. Intune has additional confusion beyond the two Intune specific portals in that license management can be done from either the Azure AD blade or from within Office365.

Of course, you can also assign the licenses using PowerShell from a computer with the Azure Active Directory Module for Windows PowerShell installed. I like this option as it can be integrated into a more complete automated user provisioning process. For example, you could create a PowerShell script that does the following:

  1. Create a user in AD (or Azure AD)
  2. Add the user to appropriate groups
  3. Assign an Office 365 license
  4. Turn on MFA
  5. Create a mailbox
  6. Assign an Intune Licence

 

 

 

 

 

In this short video I’ll show you three ways to assign Intune (or EMS) licenses to users:

  1. Office365 Portal
  2. Azure Portal
  3. PowerShell
Advertisements

Co-management – Managing the transition

Posted on Updated on

This is a graphic that Microsoft used at Ignite to help illustrate the different journeys that organizations might take to get to modern management. Here’s a quick post on the last item in the table – the co-management path. Now that the key prerequisites for co-management have become available (SCCM 1710 and Windows 10 1709) have been out for a while, organizations that are considering co-management are looking at the management scenarios that are available to them. There is some new infrastructure that needs to be configured and there are a lot of good posts on those prerequisites like this one from the Microsoft Document Library so rather than focus on the technical details, I’d like to explore some of the management decisions that you might need to address:

  1. Co-management does not require a hybrid infrastructure of SCCM connected to Intune. It actually requires each platform to run in standalone mode. That means that if you have a hybrid environment, you will need to migrate to a standalone Intune model.
  2. Not all workloads are available in both platforms so you will need to choose what makes sense to move from SCCM to Intune. For instance, Win32 application management is easier in SCCM and most organizations already have an established release management process around it. Compliance policies on the other hand are often better suited to be managed with Intune as it provides a richer experience and more advanced controls for things like Device compliance policies, Resource access policies, and Windows Update policies.
  3. In other cases, the workload may not be available to be migrated to Intune or may not be an easy transition. Examples include Endpoint protection and Operating System Deployments. If you have a requirement for upgrading Windows 7 devices to Windows 10, SCCM is still the best option.
  4. Are you going to start with Intune managed devices and then add the SCCM client or are you going to start with SCCM Managed devices and enroll them into Intune?
  5. Ho do you want to address non-Windows 10 devices?

As exciting as new technology is, there is always value in understanding your use case scenarios and requirements before embarking on any new initiative. As a friend of mine constantly reminds me, “Businesses don’t care about the use of innovative technology but the innovative use of technology”.

Windows 10 Updates – Order from the Chaos

Posted on Updated on

Since the original release in July of 2015 there have been six versions of Windows 10 released in total:

  1. Version 1507 (Codenamed Threshold 1)
  2. Version 1511 (Codenamed Threshold 2 aka the November Update)
  3. Version 1607 (Codenamed Redstone aka the Anniversary Update)
  4. Version 1703 (Codenamed Redstone 2 aka the Creators Update)
  5. Version 1709 (Codenamed Redstone 3 aka the Fall Creators Update)
  6. Version 1803 (Codenamed Redstone 4 aka the Spring Creators Update)

Microsoft’s near term roadmap is to release two more feature updates every year. Version 1809 (Codenamed Redstone 5) is due later this year.

The number and frequency of releases coupled with new servicing models has led to a lot of confusion in the industry around managing servicing branches, quality updates vs. feature updates and the cadence of the release cycle of Windows as a Service (WaaS). In this post I’d like to focus on two simple things you can do to simplify your windows 10 updates if you are using System Center Configuration Manager (SCCM).

  1. Automatic Deployment Rules (ADRs)
  2. Filters

ADRs let you automate how, when and what software updates are applied to your systems using repeatable, template, scheduled business rules. There are many good posts on ADRs and some very good videos by Jason Sandys (A fellow MVP) so I’m going to focus on Filters.

If you are using SCCM to update your Windows 10 systems you will notice that in the Software Updates there are a lot of Windows 10 updates. That is because as we know there are many different Windows 10 versions. Most organization will not be running all versions and do not need to be bothered with many of the available updates. For instance, if you search for all Windows 10 updates, you will see more than 150 updates. If you are only running Windows 10 1703 the majority of those updates will not apply to you. If you use a filter, you can reduce the number of irrelevant updates significantly. Consider this ADR filter:

It returns at all updates for Windows 10 limited in the following ways:

  1. The 64 bit Windows 10 1703
  2. Updates that haven’t been superseded
  3. Updates that are classified as either Critical, Security, Update Rollups or Updates

This filter reduces the number of updates in the update group from over 150 to just 4 items.  A little bit more manageable.

You may also notice that I have added the keyword “Malicious” to include the Malicious Software Removal Tool (MSRT) as I find it useful to include in my ADRs.

You can use the search criteria in a similar way if you are creating software update groups manually.

I use filters regularly to help organize my software update groups and create some order from the chaos that is Windows 10 updating.

Windows 10 Updates – The Rules they are a Changing

Posted on Updated on

Microsoft announced on February 1st that they will be adding another six months to the supprot of Windows 10 version 1607, 1703, and 1709.

Release Release Date End of Support End of Additional Servicing for Enterprise & Education
Windows 10 1511 November 10, 2015 October 10, 2017 April 10, 2018
Windows 10 1607 August 2, 2016 April 10, 2018 October 9, 2018
Windows 10 1703 April 5, 2017 October 9, 2018 April 9, 2019
Windows 10 1709 October 17, 2017 April 9, 2019 October 9, 2019

Up to this point Microsoft has offered 18 months of support for each Windows 10 release. This extension seems a direct repsonse from enterprise customers struggling to keep pace with the rapid release cycle and short support windows associated with Windows as a Service.

Windows as a Service isnto only new for customers. It’s new for Microsoft as well. As they figure out how fast customers can ingest all of the innovatiosn comign out of Redmond, we’ll see the release cycles stabailze and balance update frequency with upgrade readiness.

For organizations that are having trouble transitioning engineerg efforts traditional associated with operating system updates to a more operational model, tools like Intune and SCCM can help accelerate the transion. I’ll be writng a few pieces in the future on how to take advantage of these types of tools to simplify Windows 10 update management.

Windows 10 SCCM & Intune Co-Management

Posted on Updated on

Is SCCM right for you or is InTune a better fit? Why choose? Use Both!

Beginning with the Fall Creators Update for Windows 10 (aka 1709) Windows 10 devices will be able to join both on premise AD domains as well as the Azure AD service. This opens the door to have devices managed by both SCCM and Intune. While administrators can use co-management to split up specific servicing workflows such as using SCCM for application deployment and Intune for update management so that devices get updates wherever they are, the co-management bridge is intended to simplify the migration to cloud based modern management services and not a long term solution. It would be really nice to be able to mix and match servicing scenarios so that as a device moves between on premise and off premise they are serviced by the most appropriate tool however at first glance this functionality is not readily apparent.

Now that Autopilot is available for Operating System Deployments, Intune + Autopilot provides a credible solution for full device lifecycle management for many use case scenarios. I expect to see more organizations using the co-management bridge to begin their migration to modern management.

Windows Autopilot vs System Center Configuration Manager

Posted on Updated on

I previously mentioned that I was excited to compare Windows Autopilot with System Center Configuration Manager (SCCM). Well, we finally have more details about Windows Autopilot and I’m finally able to give you a comparison of Autopilot and SCCM for Windows 10 deployments.

System Center Configuration Manager

Before I dive into Windows Autopilot, let us review the typical use cases for SCCM so that we have a basis for comparison. SCCM is an on premise tool that performs many functions in addition to Operating System Deployment (OSD) however; I will just focus on the OSD portion for now. Here are the three most common OSD scenarios:

Scenario 1 – Boot Media

This is a Light Touch deployment requiring physical access to each device. It is well suited to small remote offices or a small staging area without OSD infrastructure (Distribution Points etc.).

  1. SysAdmin creates a custom Windows Image, driver package(s) and task sequence
  2. SysAdmin either creates boot media
  3. Boot media is distributed to required locations
  4. Each device is booted with the boot media and the task sequence builds the device
  5. Applications can be added in the task sequence or post OSD through SCCM’s Software Deployment functionality

Pros

  • Minimal network impact
  • Minimal infrastructure requirements

Cons

  • Requires visiting each device (Light Touch)
  • Boot media management overhead

Scenario 2 – PXE Boot

This is a Light Touch deployment requiring physical access to each device to enter PXE boot – This can be made Zero Touch if the boot order is set to PXE first however, this is not a sustainable configuration. It is well suited to a large staging are or small remote offices with OSD infrastructure (Distribution Points etc.).

  1. SysAdmin creates a custom Windows Image, driver package(s) and task sequence
  2. Sysadmin deploys task sequence to a collection of devices
  3. Devices are booted and forced into network boot
  4. The device finds a boot image from the SCCM Distribution Point and
  5. Each device is booted with the boot media and the task sequence builds the device
  6. Applications can be added in the task sequence or post OSD through SCCM’s Software Deployment functionality

Pros

  • No media management
  • Easy modification of task sequences, boot images and driver packages

Cons

  • Requires visiting each device (Light Touch)
  • Requires complex infrastructure

Scenario 3 – Deployed Task Sequence

This is a true Zero Touch deployment that can be used a Self-Service option as well as a scheduled mandatory deployment. It can even be coupled with Wake-on-Lan to target devices that are powered off (but still connected to the network. This is well suited to upgrading or refreshing large numbers of devices currently in use as it requires that each device is already managed with SCCM.

  1. SysAdmin creates a custom Windows Image, driver package(s) and task sequence
  2. Sysadmin deploys task sequence to a collection of devices
  3. Task sequence is executed on device (Self-serve or scheduled)
  4. Required files are copied to the device and the device reboots and the task sequence deploys the operating system
  5. Applications can be added in the task sequence or post OSD through SCCM’s Software Deployment functionality

Pros

  • No requirement to visit each device (True Zero Touch)
  • No media management
  • Easy modification of task sequences, boot images and driver packages
  • Supports Self Service
  • Supports Scheduling

Cons

  • Requires complex infrastructure
  • Only available to existing SCCM clients

Windows Autopilot

Windows Autopilot is a cloud-based service that does not require any special infrastructure. Here’s a typical OSD scenario using Windows Autopilot:

  1. SysAdmin creates device profile(s)
  2. Sysadmin registers the device(s) with the Windows Autopilot service
  3. SysAdmin assigns a profile to the device(s)
  4. Device is booted end user
  5. Device is connected to network (any Network – home, work, public)
  6. User provides enterprise credentials, Language and Keyboard settings
  7. Device self configures based on assigned profiles
  8. If the organization uses Intune additional polices and applications may be delivered to the device

Pros

  • No requirement to visit each device (Near Zero Touch)
  • No media management
  • Easy modification of profiles
  • Supports Self Service

Cons

  • Cloud service (may be a con for some organizations)
  • Eliminates requirement of staging areas and internal device shipping
  • No support for system upgrade (maintaining user data and state information)
  • No support for complex configurations (multi partition, etc.)

Conclusion

InTune has been evolving rapidly over the last few years and has been able to provide much of the same functionality as SCCM such as hardware and software inventory, application management, software updates etc. The one feature that missing was OSD. Coupled with Windows Autopilot, Microsoft InTune is a credible end-to-end lifecycle management platform for many use cases that requires no on premise infrastructure. While it cannot service all of the use cases that SCCM can, it can save time and money for organizations where it is a good fit.

SCCM as a Service – Upgrade Checklist

Posted on Updated on

As System Center Configuration Manager (SCCM) matures into an “as a Service” model, the ability to rapidly upgrade an infrastructure has come a long way. It used to be complex and time consuming to upgrade SCCM as you would have to download all the prerequisite media test everything in your lab and then schedule the downtime in your production environment. With the advent of SCCM Current Branch (CB) the ability to upgrade directly from the console has made this much less complex and in theory less error prone. This doesn’t mean you shouldn’t take precautions and test before rolling to production. Here’s some advice on how to manage the risk associated with the upgrade:

  1. Backup your environment and test the restore in case you need to rollback. You do this regularly anyways right? There are several supported backup options for you select from based on your particular requirements. Here is some backup and recovery guidance just in case
  2. Check your site and component status to make sure you don’t have any unresolved issues that might impact the upgrade. Check them again post upgrade.
  3. Perform the prerequisite check
  4. Test everything in your lab, sandbox, or test environment before upgrading in production. You don’t have a test environment. Well you do you just like to call it “production”. You can setup a really simple and inexpensive virtual lab in Azure that you can spin down when not in use.
  5. Use Pre-pilot collections to test client agents. This is a great way to minimize the impact of client agent defects.
  6. Check that all of your site systems have been upgraded
  7. Test basic functionality such as HW and SW inventory and Software Updates. This puts the basic components such as MPs, DPs, SUPs and client agents through a smoke test.
  8. Test task sequences especially if there was an ADK upgrade involved
  9. Check if there is a newer version of MDT available / required in order to work with particular ADK you are using and to support any required servicing branches
  10. Test the console update and any extensions such as Report Builder
  11. Test any pre-release features that you were previously using. Are they now released? Do you need to reenable the functionality as pre-release?
  12. Is this version available as a baseline build? Do you want to keep an ISO handy?
  13. Check for any post upgrade hotfixes.