Endpoint Manager OMA-URI Settings - Restrict Parts of the Settings App

This blog covers how you can control what users can and can't see in the settings app in Windows through Endpoint Manager.

RESTRICTING PARTS OF THE SETTINGS APP

You can use the device restrictions template to block whole sections of the settings app in Windows such as the Devices section. But what if you wanted users to only access the bluetooth page under the Devices section? This is where OMA-URI settings come in to let you get that fine grain control over what users can access.

The OMA-URI we are using here is the ./Device/Vendor/MSFT/Policy/Config/Settings/PageVisibilityList which allows you to filter down what you want your users to see.

Now when settings this up, you have two options:

• Show Only
• The pages and sections you define are shown, but everything else is hidden.
• If you put only show the System > About page then that's all the users will see.
• Hide
• Hide will only hide the pages you define in your Configuration Profile.
• If you say hide the VPN option under Network then every option in settigns will be shown but VPN.

To decide which option to use, depends on what you want blocking. Do you want to hide 90% of the settings options? Then use show only. If you only want to hide a few options then it'll be easier to use the Hide option.

CREATING THE OMA-URI CONFIGURATION PROFILE

Set up a new Configuration Profile and you want to use the Custom template to allow you to create a OMA-URI entry. For this entry, I have my setup below as an example

• The Name can be anything you want.
• OMA-URI is ./Device/Vendor/MSFT/Policy/Config/Settings/PageVisibilityList
• The value is your pages you want to block which is covered below.
  

BUILDING YOUR OMA-URI VALUE

The value starts with either showonly: or hide: depending on which one you want to choose. After that you need to use the URI name of the page you want to either hide or show then use the semicolons ; to separate them. Below is the URI values, you don't need to include the ms-settings part like shown in the configuration above. 

These tables were taken from the Microsoft Docs site linked below

Launch the Windows Settings app - UWP applications | Microsoft Docs

What are VRFs? (Virtual Routing & Forwarding)

This blog covers what VRFs are and how you would set them up in your network.

TRADITIONAL ROUTING & INTRO TO VRFs

Typically, your router will have a routing table compiling all the known networks with all the possible routes. This is a sole table for all interfaces and subnets. For an organsation that handles one evnironment this is perfectly fine but what if you were a service provider with multiple customers using your network for technologies such as MPLS? This is were VRFs come in.

A VRF is the layer 3 version of a VLAN found at layer 2. With VLANs, you split up your broadcast domains into separate layer 2 domains, assosiating interfaces with a specific VLAN for it take part on that subnet. VRFs work similarly to this. You create your VRFs like you would a VLAN, and then you associate your interfaces with a VRF. Like VLANs, these VRFs are segragated from one another and only see other interfaces that are part of the same VRF.

The router no longer has a sole routing table, there's one for each VRF. As you associate an interface with a VRF, it is taken out the main routing table and put in the VRF's routing table. The built in routing table of the router won't even see that the interface exists. This segmentation of the routing does allow for configurations you wouldn't typically see such as the ability to have duplicate IP addresses on other VRFs and it's perfectly fine. They are virtually separate so there's no conflicts.

VRF USE CASE

VRF is used with service providers running MPBGP in MPLS as it allows them to segement custmer traffic over a WAN environment. The lighter version, VRF-Lite has even more use as it doesn't require MPBGP so places like data centers or large networks can use VRF-Lite to segment traffic for DMZs, extranet and internal to group traffic into zones.

Below shows an example of an ISP with two cusotmers. There's two VRFs for each one, the customers can only see the links part of their VRF so the customers won't see one another but the ISP can still manage both.

HOW IS IT CONFIGURED? 

VRF is configured similar to VLANs where you create the VLAN, assosicate an interface with said VLAN. The image below shows a router with 2 interfaces being assosicated with different VRFs and the console showing the commands. (You can even use one physical interface for multiple VRFs by using subinterfaces then associating each one with a VRF)

At the bottom, you can see you can look at the IP routing table for a specific VRF as well as setup OSPF for a specific VRF.

Data Redunancy for Azure Storage

This blog covers the various options available for data redundancy in Azure.

AZURE DATA REDUNDANCY

Data in Azure is replicated 3 times in a single site at the lowest cost level, the options are:

• Locally-Redundant Storage (LRS)
• Zone-Redundant Storage (ZRS)
• Geo-Redundant Storage (GRS)
• Geo-Zone-Redundant Storage (GZRS)

LRS - LOCALLY-REDUNDANT STORAGE

LRS will replicate your data 3 times across a single datacenter in your primary region. This is the lowest cost option as it provides basic redundnacy, protecting against failign drives or server racks but if something affected the whole datacenter then all copies of the data are affected.

 

 

ZRS - ZONE REDUNDANT STORAGE

Zone Redundancy takes it a step further by replicating your data across 3 availabilty zones in your primary region. Each of these availability zones are separate physical buildings with their own power, cooling and networking.

This protects you by allowing data to be accessed if a datacenter goes down as you will have two others for accessing your data. ZRS supports read / write operations which happens synchronously to all copies when writing to a file. If one zone does go down then Azure will handle re-pointing DNS to keep the data accessible.

 

 

GRS - GEO-REDUNDANT STORAGE

When you create a storage account, you select its primary region. Azure Regions have pairs, your primary region will have a distant pair which can be used for redundancy.

GRS is LRS but over two regions. In your primary region, your data is copied 3 times within a single physical site. The sam data is then copied to the paired region where it is copied 3 times again in a single physical site.

 

 

GZRS - GEO-ZONE-REDUNDANT STORAGE

This takes the ZRS concepts but adds a second LRS backup in the paired region. It behaves like ZRS coping the data over 3 availability zones in your primary region but then uses LRS in your paired region to have 3 copies of your data within a single physical site in the secondary region.

 

Wireless Topologies Explained (BSS, ESS and SSIDs)

This covers wireless topologies, going over BSS, ESS and SSIDs

CONNETING TO A WIRELESS NETWORK

When you connect to a wireless network, you typically connect to an available SSID then away you go. Once connected you can freely move around a building, moving from one access point to another access point all while still connected to the same SSID.

To manage the connected clients, wireless networks use BSS, ESS and SSIDs to enable mobility.

BASIC SERVICE SET (BSS) 

Thinking about SSIDs, you see it as one overall network for a whole building/campus where you are connected to just that wireless network. That WLAN is made up of access points all broadcasting the SSID for clients. As people connect to the SSID, they also connect to the access point within range.

Each access point has its own local wireless network which covers the broadcast radius of the access point's radios. This local WLAN of the access point is a BSS. For a WLAN, it isn't just the SSID of the whole building/campus but it is also multiple BSS networks that make up the foundations of the network.

Each BSS has an ID that the WLAN uses to track which AP a client is connected to and to ensure each BSS can be uniquely identified. If you go into CMD or PowerShell in Windows, you can use the command 'netsh wlan show interfaces' to see what the BSSID is of the BSS you are connected to. Below is an example.

EXTENDED SERVICE SET (ESS)

Extended Service Sets are basically what we typically call SSIDs. An ESS is a collection of BSSs that are broadcasting the same SSIDs to allow clients to roam between the APs. Below is an example of multiple BSS networks making up a larger WLAN to form an ESS.

SERVICE SET ID (SSID)

SSIDs are friendly names for WLAN networks. BSS networks have a BSSID which is the MAC of the broadcasting AP but SSIDs make things easier. For an ESS, there is no ESSID but the SSID giving it a friendly name removes the need for an ESSID. SSIDs are used for both BSS and ESS as it's easy to have the consistancy and avoids having to use the BSSID.

Automating Autopilot Deployments via Dynamic Device Groups

This covers automating the process of assigning Autopilot deployment profiles, apps and policies to Intune devices.

SETTING UP YOUR ENDPOINT GROUPS

When importing devices into Endpoint Manager, you need to place the device in a group within Azure AD for it to pick up an Autopilot deployment profile then pick up any apps and policies you targeted towards that group after enrollment. 

If it's one or two devices, it's not much work importing the devices then manually adding them to the group but it isn't going to be fun adding 50+ devices to a group. Here's were dynamic device groups come in handy. You can build dynamic groups based on the Group Tag field of Autopilot Devices. 

When generating the hardware ID of a device, you can set the Group Tag at the same time. You can use this tag to automate which group it joins in Azure AD once you've imported them. The rule below is used to match devices with specific Group Tags. The property is "devicePhysicalIds" with the value being "[OrderID]:TAG" replacing TAG with your group tag.

In my example I have used "Marketing" as my Group Tag. This particular group may be for Marketing devices that gets Marketing specific policies and apps. I could have a second dynamic device group for a different department that has different software and policy requirements, using a different Group Tag for them.

This can simplify the build process of devices to just, gather the hardware IDs whilst setting a Group Tag at the same time, importing your CSV file and then going through the OOBE once they have all been imported and have an Autopilot deployment profile assigned.

ASSIGNING A GROUP TAG WHEN GATHERING THE HARDWARE ID

The PowerShell cmdlet to generate the hardware ID has a parameter of -GroupTag followed by a value for your Group Tag such as "Marketing". If you're doing multiple then also use the -Append parameter to append each individual device to the next row of the CSV.

Adding Additional Local Administrators on Azure AD Joined Devices for Endpoint/Intune

 This covers how to define additional users as local admin on Azure AD joined devices.

CREATING AN AZURE AD GROUP FOR YOUR ADMIN USERS

Within Azure Active Directory, you need to create a group that will be used to define which users should be added to the local administrators groups for AzureAD joined devices, important if your environment is built upon Intune/Endpoint Manager.

The group needs to have the 'Azure AD roles can be assigned to the group' set as YES. This is so AzureAD can assign the local device administrator role to the users in that group.

SETTING THE GROUP AS LOCAL ADMINISTRATORS ON AZUREAD DEVICES

Within the Azure Portal under Devices, select the 'Device Settings' section then at the bottom is 'Additional local administrators on all Azure AD joined devices' where you define additional local administrators.

The link should open the screen shown below. You can use the 'Add Assignment' to add your AzureAD group to be used as local administrators on all Azure AD joined devices.

Once you have set your group with the assignment, you should be able to log into an Azure AD joined device and automatically be added as a local administrator.