I haven’t been on my game this week. If we’re honest, I think a lot of us have been a little bit off. Covid-19 has been looming for months, yet somehow we failed to anticipate how the virus would impact our daily lives. In North America, we watched as the pandemic exploded first in Southeast Asia then quickly moved across Europe. Most of us expected we would see it here, but I think that in our hubris we never expected a major disruption to business and society. Our culture isn’t one to slow down. We tend to believe we are above the fray and can weather any storm.
It’s not a secret that I claim to be a technology disruptor. As IT pros working with Microsoft 365, we want to change the way that our organizations work. Our goal is to empower our end users. Change typically takes time and being a disruptor in technology is as much about being a salesman as it is about being a skilled technologist. We are used to pitching new solutions, talking about the benefits of new technology, and working to build allies in our organizations. Workplace disruption is typically a slow and methodical process. Even if we know the value these tools have it can take time to deploy them because of the impact they would have on end users, infrastructure requirements, and workplace culture that isn’t always ready for change.
Six months ago, we couldn’t have predicted the impact a global pandemic would have on the workplace. What was once unthinkable is now our reality. The disruptors have now joined the ranks of the disrupted. Pitching a modern workplace was always about creating a nirvana that would empower workers to work from any location, on any device with total security and unlimited freedom. It sounds great on paper, but a lot of organizations weren’t ready to adopt remote work models, so change was incremental. Many of the modern workplace tools were considered ‘nice-to-haves,’ but not essential for continuing day to day operations. Our roadmaps have been filled with bucket list items from the Microsoft 365 suite of tools, but for most of us those tools aren’t deployed yet. However, we can’t unmake decisions that were made six months ago. It would be easy to say, “If we had deployed Teams globally six months ago, we wouldn’t be in this situation,” or, “If we had only decided to set up a Cloud management gateway or co-manage our Windows 10 devices we could address this issue on PCs.”
This post is a follow up to my post on customizing language settings in a Microsoft Endpoint Manager task sequence using UI++ and a custom unattend.xml file. I will continue this series in a third post that discusses the native functionality in MEMCM 1910 and later.
In a post a few weeks ago I discussed my process for managing languages in a Microsoft Endpoint Manager task sequence. That post went in depth on using UI++ and a custom unattend.xml file to allow a technician to select a primary language and alternate keyboard layout during OS deployment. That process requires having a Windows image that already has language packs and features on demand injected. I briefly discussed my process for creating a WIM file.
That post mentioned that I initially created a WIM file with WimWitch from Donna Ryan (@theNotoriousDRR). I would create the image, run my own script to inject the languages and features on demand, and then update the WIM using WimWitch. At that point WimWitch did not support language pack injection. Donna had mentioned that language injection support was coming – but I didn’t know when it would be available. Shortly after posting my last post she released the 1.4 beta release of WimWitch which previewed the language pack injection! WimWitch version 1.4.1 is now available. The language support is excellent!
I was originally going to write about my own script, but Donna hit this process out of the park. With each new version, WimWitch adds amazing new features that could only be designed by someone who is familiar with MEMCM, the imaging process, and has an excellent eye for detail. If you aren’t already using WimWitch, take the time to explore all of the features that are currently available – it’s a great tool and new features are being added regularly!
I was recently asked to create a simple process to change the primary language of Windows 10 during OS Deployment. Due to regional expectations we also had to be able to select a different keyboard layout based on user preferences. One of the challenges we face is that we have support personnel in different regions, but not in all offices. Our remote offices did not have a centralized imaging solution, which meant that we needed to provide a solution and streamline the process.
My goal was to provide a solution that would be easy to understand, simple to execute, and easy to maintain across different regions. My personal preference is a simple task sequence that minimizes the number of conditional steps needed to execute.
In this case I wanted to provide our technicians with a clean user interface. I wanted to avoid using DISM to inject languages during the task sequence, which in turn prevents me from having to manage additional content used in the task sequence. The task sequence should be lite-touch, prompting for basic information like site code, form factor, language settings, and additional applications.
Microsoft Endpoint Manager 1910 added support for language settings to the “Apply Windows Settings” step. This would be a great solution if you have a small number of configurations to support, but in an environment with a multitude of possibilities it could be difficult to manage. I will cover using these settings in a future blog post as I think they are an excellent addition to Configuration Manager, they just don’t meet my needs for this project.
Most of the other documentation that I found required integration of MDT with SCCM. The posts that did not use integrated MDT used some elements of MDT or other scripts to set these values. I considered that option but wanted to see if I could get by without the additional steps.
When I saw that language support had been added to the task sequence I decided to test whether or not I could set the language settings without the use of a script. This may have worked prior to version 1910, but I have not tested it. I suspect that this functionality is a direct result of the settings being added to the task sequence directly.
After looking at different possible solutions I determined that the best way to create a technician-facing UI was UI++ by Jason Sandys of ConfigMgrFTW. UI++ gives me the ability to create a simple UI that can be easily customized and ported to other locations. I can use one deployment package for all my locations and point to a different XML file based on the region.
Have you ever deployed a Conditional Access policy, only to later discover that users had found a way to circumvent it? It is surprising to discover that someone found a way around your carefully designed and tested policy.
Setting up Conditional Access policies can get confusing. If you don’t plan your policies carefully, you may end up with holes that you didn’t expect. Most of us start by thinking about the scenarios we want to allow. The problem with this approach is that if you only think about what you want to allow you may forget to block scenarios you don’t approve. Without a policy in place to block unapproved scenarios, a malicious actor can exploit those scenarios by simply providing a user’s compromised credentials.
For example, consider this scenario: You are asked to create a policy that will allow a user to access their email on an iPhone. You will allow a user to use the native mail application with ActiveSync or Outlook if the application is protected by a Mobile Application Management policy. The policy you create is applied to the user, targeted to Exchange Online, and applies to ActiveSync and Modern Authentication clients. Controls are set to grant access if the device is compliant or if a MAM policy is applied.
When you test the policy and the device is not registered you are blocked from accessing the application in the ActiveSync client. The Outlook application prompts you to install the Azure Authenticator to access the application. Once the Authenticator app is installed or it is enrolled the user can access their mail in the targeted applications. This policy works as designed; users must meet one of the controls in the policy to use their email as intended. You may consider the policy successful and move it into production. However, there’s just one problem…
My name is Sean Bulger. I am an IT Pro that has worked in the Modern Endpoint Management work space since 2015. I have worked in various environment, ranging from mature enterprise all the way down to a fledgling IT organization looking to find their way in a cloud first world. Before rejoining the technology field in 2014 I had a wide range of careers - from plumber to paramedic - that have helped to shape my perspective on the world.