Unable to enable Javascript on iOS device

While setting up a new iPhone that was enrolled in MDM and using Intune, I came across an issue when setting up the Qantas app on iOS.

When you attempt to login to the Qantas app to set it up for the first time you are shelled out to Safari and here it needs to use Javascript to complete its login process. Unfortunately, if you have Javascript disabled then you get a nasty error message that you need to enable it and you can go no further.

file

No problem, you think. I’ll just go into the device Settings, Safari then Advanced where you expect to see the above Javascript option. Only problem is, that for some reason, you can’t change this option because it is disabled for some reason.

image

In my case, the reason why it was disabled is because I had an Intune Device Restrictions policy in place that was blocking Javacript. You change this option by going into the iOS restriction policy, selecting Settings, Built-in Apps, Safari, Javascript as shown above. Change the setting from Block to Not configured, then Save the policy change and allow a few minutes for the policy to be applied to the device.

After that, I was able to re-run the Qantas app configuration and set up everything as expected. You could then, if course change the policy back if you wished to block Javascript going forward.

The lesson here is, that if something is blocked on your device that is managed by Intune, then most likely that setting is being controlled by an Intune policy and you’ll need to make the change there.

Windows Information Protection (WIP) in action

Windows Information Protection:

“helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps”

It is a technology that is limited to Windows 10 desktops and is typically deployed via Intune using App Protection Policies.

image

To get there you’ll need to navigate to the Microsoft Intune service in the Azure portal and then select Client apps from the menu on the left.

image

You’ll then need to select App protection policies.

image

You’ll need to create a policy if one does not already exist.

For Windows 10 there are two policy options, with and without enrolment. The difference is that “with” enrolment the machine is effective using MDM (device management) and is typically directly connected to Azure AD. “Without” enrolment is typically just MAM (only application management) and is typically not directly joined to Azure AD. I’ll focus on a “with enrolment” option here but “without” is pretty much identical in the options provided.

image

Once the policy is in place don’t forget that you’ll also have to assign it to a group of users for it to take action. However, before you actually assign it to live set of users in your environment, you may want to take a moment to understand the ramifications of what the policy will do.

If you examine the Required settings of the policy, as seen above, you will see that you can set an option for the Windows Information Protection mode. If you are just testing things and don’t want to impact or change your environment then I recommend the Silent option. If however, you want to have the policy protections enabled but want a choice when it is applied, select Allow Overrides (recommended). If you want to be totally strict about applying the policy to your Windows 10 devices, select Block.

The domain for your tenant should appear in the Corporate identity field below. If you have any addition domains you use, ensure they are entered in this field.

image

If you then examine Advanced options, as shown above, you should see that an existing entry for Cloud resources already exists. When you drill into this, it should contain your Office 365 environment. I spoke about this location more in a previous post:

Intune App Protection blocking browser

and noted that you may need to make some adjustments to it to allow non Microsoft browsers on Windows 10 machines.

The interesting part is now if you also have on premises infrastructure you wish protected. So, imagine the Windows 10 devices are accessing data from Office 365 and from a local file server. By default, this local infrastructure will be considered ‘personal’ and won’t allow saving of corporate data there. In essence, Windows Information Protection (WIP) prevents corporate data being saved to personal locations. By default, your Microsoft 365 environment will be configured as a corporate data location but local fileservers will not be. Thus, if you wish to have your local infrastructure also classified as corporate data, then you need to specify your local DNS domain and IP range as I have done above as a Network Boundary. However, be warned, this has other implications that you need to consider which I’ll speak about later.

image

There are additional options if you scroll down further. When data that is protected by WIP is stored on a device covered by this policy, it will be protected by WIP encryption at rest. An option here in the policy allows you to revoke these encryption keys if the device is ‘unenrolled’ from Azure AD. That means, the moment the device is removed from Azure AD, any corporate data will be unable to be read since the encryption keys will be revoked for the device. You can generate and upload a recovery agent as you see above if required, however modern Windows 10 releases will actually recover the key from Azure AD if that same machine is re-joined again to Azure AD.

I have also select the option to Show the enterprise data protection icon which will appear on documents WIP considers corporate data. This is always a good way to distinguish corporate data, so my best practices is to have it there as a reminder.

You’ll also see that you can use Azure RMS (rights management) with WIP if you want. I’ll leave this disable for simplicity now, but if you want that extra protection that Azure RMS gives, then it is available if you have a license for RMS.

image

If those options are now saved to the policy and the policy is actually assigned to a set of users, once the policy has been fully assigned to a device you will see something like the above.

Here you will notice that all the OneDrive for Business files have been classified as corporate data as noted by the briefcase graphic in the file type icon. You will also note a new column as well – File ownership, which contains the domain you configured.

image

If I look at the data on a local file server I see the additional File ownership column again, with all data being owned by my domain.

Thus, all data from Office 365 and my local infrastructure is now considered corporate, not personal, data. This means that it can only be accessed using the apps I have authorised to access corporate data in the policy.

image

So how does this all work in practice? As an example, I created a new data file on the local Windows 10 device subject to the App Protection policy. This file is currently considered a personal file because it doesn’t have the briefcase graphic in the file icon.

image

I can change the file from personal to corporate by right mouse clicking, selecting File ownership and then picking the option that I want. Here’s I’d choose Work (ciaops.com) to swap that file to being considered corporate data.

image

Once I make the option to categorise it as corporate data, you’ll see the logo changes immediately to indicate the file is now managed. The file has also now been encrypted by WIP on the local device for protection. The user doesn’t see this as the WIP encryption/decryption is handled seamlessly behind the scenes on the device.

image

Now that this data is a corporate file, only apps that I have defined as corporate apps can open that file. You’ll see above that Notepad will work on both types of files, corporate and personal, but what happens if you try and open this corporate file with a non corporate app like Wordpad, which, as you can see, says it will only open personal files?

image

What happens, is that the corporate file cannot be opened by the non corporate app as shown above and I get an denied message.

image

You’ll see that I get a similar result if I try and copy data from a corporate app and attempt to paste to a personal app. Because I set the option earlier in my policy to Allow Overrides, I see the options shown above indicating that I can proceed pasting corporate data into a non corporate app but the actions may be tracked.

image

The way that I can tell whether the data in the file is being protected and considered corporate is with a small briefcase icon in the upper right as shown above.

image

If I select this icon I get further information that the app is being managed by my domain as shown.

This means in summary, that you can use WIP applied via Intune App Protection policies to ensure that defined corporate data does not end up in non corporate locations. WIP corporate data while stored on a Windows 10 device is protected at rest by encryption.

Also, remember that not all Windows 10 devices will be enrolled into your Azure AD. Some may just be associated (typically BYOD). By implementing a Windows 10 App Protection policy Without Enrolment you can protect the corporate data that is on these device as well. A good scenario here is to imagine a user’s personal Windows 10 Home machine that they use to access corporate data after hours to work on while not on their corporate joined devices. This means you can protect data even on Windows 10 Home editions machines (via a  non enrolled App Protection policy).

There are some issues to be aware of here, especially when you start mixing WIP with on premises locations. The best way to explain this is via an example I’d suggest. I set up WIP to include my local server and when the policy applied, all the data on that server was considered corporate. The apps that I used are mainly those that were set up in the Intune policy such as Word, Excel, etc as well as some custom apps like Adobe Acrobat Reader which I have detailed how to do here:

Adding Acrobat Reader as an Allowed app

Where things came unstuck a tad was when I wanted to use a not so common app like Keypass. The Keypass app lived on my Windows 10 machine but that data lived in the on premises server. Thus, the Keypass app could only open ‘personal’ data but all the data on the local file server, including the Keypass data file, was now ‘considered’ corporate data thanks to the Network Boundary settings in the policy. In short, I couldn’t open the data when I needed to. Moving the data file to other locations didn’t help either as it was still considered corporate data and the Keypass app could only open personal data. Annoying to say the least.

In the above scenario, with a small number of custom apps required to open data, you could add these custom apps to allowed list of apps in the policy so they are permitted to work with corporate data. If that becomes to hard then you probably need to evaluate whether you want your on premises infrastructure classified as ‘corporate’ data. However, failing to do that means you can’t copy from locations defined as corporate, such as Office 365, to these.

image

As you can see from the above, when I attempt to copy from my OneDrive for Business (corporate location) to a location that is considered non-corporate (local server) I get the above. Because I specified the ability to override I do get a bypass option but you’ll see when I do that, the data I copy will have it’s corporate protection removed and reverted to a personal data.

The key message is therefore that implementing WIP is something you need to think about carefully and plan prior to implementing. If you get it wrong then it will be a huge source of frustration for users, However, implemented correctly it is yet another way to protect your corporate data on both managed and unmanaged Windows 10 devices.

Adding Acrobat Reader as an Allowed app

When you set up an Intune App Protection Policy for Windows 10 you are effectively enabling Windows Information Protection (WIP). This is designed to protect your business information being shared with non-business approved applications. This means there are a range of standard business ‘approved’ applications that are enabled by default. These are typically ‘enlightened’ apps that can differentiate between corporate and personal data. This allows them to abide by the policies set in the Intune App Protection policy you create. Applications that are not ‘enlightened’ are typically blocked from working with corporate data.

In a previous article:

Intune App Protection Policy blocking browser

I detailed how this could affect third party, non-Microsoft browsers, like Chrome, accessing the Internet. That article, also showed you how to easily overcome that issue with some minor configuration changes.

In this article I’ll look another way that ‘non-enlightened’ apps get blocked and how you can easily enable them.

image

So, let’s say that you have created an Intune Windows 10 App Protection policy like that shown above. When you do you configure a number of Protected apps as you can see. Typically, these a Microsoft products like Office, Internet Explorer, Edge and so on.

image

With that default protection policy successfully applied to a Windows 10 machine you can then see the data identified as personal or business on that machine now. The above shows you some files in OneDrive for Business, which is considered a business location. You can tell they are business files by the little brief case in the upper right of the file icon. Thus, all these files are considered to be business and are protected by WIP.

image

Let’s say that I now want to open the business PDF file with Adobe Acrobat Reader.

image

The result is, you are unable to do this because Acrobat Reader is not an ‘enlightened’ app. Thus, it is considered a personal app and is therefore denied access to business information.

image

To rectify this situation we need to return to the Protected apps section of the Intune App Protection policy and select the Add apps button as shown.

image

You then need to select the option Desktop apps from the pull down at the top of the screen. When you do so, you will probably see no apps listed below.

image

You should now enter the following information into the fields:

Name = Acrobat Reader DC
Publisher = *
Product Name = Acrobat Reader
File = acrord32.exe
Min version = *
Max version = *
Action = Allow

The most important item here is the filename for the program is entered correctly, (without any path) into the File field. In this case, the executable for Acrobat Reader is acrord32.exe.

Select Ok, once you are entered all the file details correctly here. Basically we are creating an exception for this app with WIP.

image

You should now see the program you just added in the list as shown above. Make sure you also Save your changes so they get applied to the policy.

Now with the policy updated, and the exemption for your app created, (in this case Acrobat Reader), you just need to wait a short time until the policy is applied to your machines.

image

With a few minutes, you should be able to repeat the process of opening that same business file and find that you can now view the file as shown above is the program that you couldn’t before.

You can now basically repeat the same process for any other custom applications you have that are ‘non-enlightened’ and you wish to have open business information saved in Microsoft 365 protected with WIP.

Intune App Protection Policy blocking browser

image

Within Intune I went and created a Windows 10 App Protection Policy.

image

I defined my Protected apps as you see above.

image

So the Required settings are as shown and utilise Windows Information protection (WIP). The idea is WIP is:

“Windows Information Protection (WIP), previously known as enterprise data protection (EDP), helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps.”

according to Protect your enterprise data using Windows Information Protection (WIP).

After creating the policy I applied it to a test machine.

image

Most things worked as expected EXCEPT that I couldn’t use non-Microsoft browsers like Chrome! I kept getting a block message as shown above. if I removed the Application Protection policy then I could browse fine on non-Microsoft apps again. Clearly something to do with the policy was blocking Chrome browsing!

The root cause is the concept of enlightened apps in WIP.

“Windows Information Protection (WIP) classifies apps into two categories: enlightened and unenlightened. Enlighted apps can differentiate between corporate and personal data, correctly determining which to protect based on internal policies.”

from Unenlightended and enlightended app behavior while using Windows Information Protection (WIP).

As it turns out, third party browsers like Chrome are considered unenlightened apps. If you read a little bit further down that article you find the following table:

image

This explains why Chrome (unenlightened app) is being blocked because it is trying to connect via an IP address effectively. Ok, so now we know why, how do we fix the problem?

image

Turns out the fix is in the last column as highlighted above. We need to use the /*AppCompat*/ string!

image

To do this navigate to Advanced settings from the menu on the left. Then select the entry you should have there called Cloud resources as shown above.

image

Here you should see your Microsoft 365 SharePoint and OneDrive sites as shown above.

image

Add the string

|/*AppCompat*/

to the end of the line. Ensure the little green tick appears on the right hand side. Select OK to close that blade and the Save to update the Advanced settings page.

image

If you now look closely on the Advanced settings page you will see the above information box alerting you to the need for the /*AppCompat*/ string if you want TLS by personal apps that connect directly to cloud resources via an IP. You can consider a third party browser unenlightened and therefore a personal app. Thus, it is telling us to do what we just did to allow third party browsers to connect to the Internet on machines where the policy is applied. Always read the configuration page eh?

Once you have saved the updated App Protection Policy and it has been applied to the devices, you should no longer be blocked when using third party browsers like Chrome and Firefox.

Organization doesn’t allow you to use work content

image

Let’s say you have a bright and shiny Microsoft 365 Business tenant that you have configured out of the box. This means you have set up the default policies, assigned licenses and installed the software for users.

Your user now receives an email like the above with a PDF attachment. The system has Adobe Acrobat reader set as the default PDF reader.

image

The user selects to open the attachment.

image

Adobe Acrobat launches as expected but you receive the above error:

There was an error opening this document. Access denied.

image

Instead, the user downloads the file to a local drive and then tries to upload it into a SharePoint Document Library as shown above.

image

They are greeted by another error:

Can’t use work content here.

Your organization doesn’t allow you to use work content here.

What’s going on? Why can’t users save files? In short, the reason is Windows Information Protection (AIP). You can read more about what WIP is here:

Protect your enterprise data using Windows Information Protection (WIP)

By default Microsoft 365 Business has WIP enabled. This means there is now a distinction between ‘corporate’ and ‘personal’ data. Corporate data is data that is created using pre-defined ‘corporate’ apps like Word, Excel, PowerPoint etc. Personal data is EVERYTHING else i.e. PDFs, files from network shares, local files. Why? Because these files were NOT created by the apps authorised by the WIP policy that has been enacted by Microsoft 365 Business.

Is there are correct way to se up WIP so you don’t get these hassles? Yes, there sure is but in this article let’s keep it simple and cover off how to disable WIP for the time being so users can get on with their work.

image

Locate the Microsoft 365 admin center and then select the Device Policies tile as shown above.

image

You should then see a list of policies as shown above. In this case, I have two Application Policies for Windows 10 (one for enrolled devices and another for non-enrolled devices).

If you have multiple Application Policies for Windows 10 you’ll need to take the following actions on each policy.

image

Select the policy to edit it. Details of the policy you select should appear on the right as shown above.

Locate the Restrict copying of company data line. Here you’ll see the Setting is ON, thus WIP is enabled. To change this setting, select the Edit hyperlink to the right as shown.

image

You should that that Prevent users from copying company data to personal files is ON as shown.

image

Change this setting to Off as shown and then select Save.

While you wait for that to sync to the Windows 10 desktops (which should only take a few moments) let’s go into the back end of Intune and see where this setting actually is.

image

Navigate to Intune in the Azure portal and select Client apps from the main menu as shown above.

image

On the blade that appears, select App protection policies as shown.

image

This should display the application policies with the same names as you see in the Microsoft 365 admin center. Here are only application policies, device policies are elsewhere in Intune.

Select your Application policy for Windows 10.

image

From the blade that appears select Required settings as shown. On the right will be displayed the state of Windows Information Protection.

If WIP is enabled, the option here will be Block.

image

However, now you have changed the policy via the Microsoft 365 admin center the setting should be Off as shown above.

This confirms that WIP is now disabled in our environment.

image

If you now return to SharePoint on the workstation, and assuming the policy has synced to the desktop, the upload of the file should work.

image

Along with everything else that was blocked, including viewing PDFs.

Thus, to overcome the WIP issues with Microsoft 365 Business out of the box, you will probably need to change the Application Policy for Windows 10  as shown above.

How do you correctly configure WIP for your environment to take advantage of all the protection it offers? Stay tuned for an upcoming article on just that.

Enrolling an iOS device into Intune

Before you can actually enrol an iOS device into Intune you typically need to complete the following preliminary steps:

Add an Apple management certificate to Intune

Set up an iOS Intune device compliance policy

Set up an iOS Intune device configuration policy

With all this done, you can now actually configure the device to be managed by Intune.

image

We’ll be using a newly wiped and configured iPhone as shown above in this walk through.

image

Note here, that this phone has both Facetime and the Safari browser on the device and available. After the device has been enrolled in Intune they will both be removed as part of the configuration policies that gets applied.

image

To do Mobile Device Management (MDM) for the device with Intune the user will need to download the Company Portal app and then run it.

image

There will be a prompt for a user login. This will be the user’s Office 365 credentials typically.

image

The device will also need to be connected to the Internet so it can verify these credentials and continue.

image

The user will now be prompted to put the device under management by selecting the Begin as shown above.

image

The user will then receive notification about what putting a device under management will mean as seen above.

In this scenario, we are assuming it is a bring your own device (BYOD).

image

The user will be given further instructions and then be required to press the Continue button.

image

The process will now try and open the Microsoft Intune portal in a browser. The user will need to select Allow to continue.

image

They will now be taken to a screen and prompted to install a new management profile by selecting the Install button in the top right.

This profile is the one that will be controlled by Intune and provide security over company data on this device.

image

The user will need to select Install again to continue.

image

They will then receive a warning about a third party certificate being installed as shown. This a certificate from Intune so the user should select Install in the top right to continue.

image

The user will be prompted to confirm that they wish their phone to be enabled for remote management.

They should select Trust to continue.

image

The management profile will complete installation. To finish this process select Done in the top right corner.

image

The user will be taken back to the Intune Company Portal app, where they will be prompted to continue. They should also now see that the device is now managed.

Select the Continue option.

image

The device settings will be checked. This is effectively running the compliance policy from Intune over the device to ensure it can be enrolled and meets the requirements to be considered to have the appropriate settings enabled and configured.

image

The process should complete without warnings or errors. This then indicates that the device is compliant and now has the configuration policies applied to it from Intune.

Select Done to continue.

image

The user will now see the Apps menu of the Company Portal app as shown above. They can return and use some of the other functionality in the app at any time but for now, simply close the app.

image

If you now look closely at the home page of the enrolled device now above, you will see, per the Intune Configuration policies that have been applied, both Facetime and Safari are no longer available on the device.

image

If an administrator now looks in the Intune portal they will see the device that has just been enrolled.

Select it to get more details.

image

They should see a summary of the device as well as a number of controls for the device across the top on the right.

image

If they select the Device compliance option from the menu on the left they will see the compliance policies that have been applied to the device and their state.

image

If they select Device configuration, they’ll see all the configuration policies that have been applied to this device and their current state.

You can select any of these policies on the right to get more information.

image

When you do you’ll see all the settings that have been applied as part of that policy. Here, you’ll see the policies for Facetime and Safari have been successfully applied (i.e. to be made unavailable on the device).

So, that’s how you put an iOS device under management using Intune. Doing so give you greater control over what is done on the and also the ability to do things like remotely wipe that device if required. A future article will show you how these management task can be accomplished on the the device.

Setting up an iOS Intune device configuration policy

Before you set up any iOS device configuration policy in Intune it is best practice to ensure:

You have added an Apple management certificate to Intune

and

You have set up an iOS Intune device compliance policy

with those two tasks complete you can now create an iOS device configuration policy. A configuration policy applies settings and configurations to the iOS device joined to this environment.

image

Open the Azure portal as an administrator and navigate to Intune. From the menu that appears on the left select Device configuration as shown above.

image

Next select Profiles from the menu on the left as shown above.

image

Here you will see any profiles that already exist. To create a new policy simply select Create policy from the menu bar across the top as shown.

image

Gove the policy a Name and Description. Select iOS as the platform.

image

You’ll see that there are lots of different configuration types you can select to create configuration policies for. In this case we’ll select Device restrictions as an example of how to configure a policy, but remember there at least 9 options here you need to consider.

Remember, you can have multiple policies if you desire as well a number of the different configuration type policies if you want.

image

If you now select Settings towards the bottom of the window as shown above, you will see the numerous range of configuration options you can set for devices.

image

In this case I’ll simply illustrate changing one setting by selecting Built-in Apps and then Blocking Facetime as shown above.

Make sure you select OK at the bottom of any screen on which you make changes.

image

The final step once you have made all your selections and Saved the policy, is to assign the policy. Here I have assigned it to All Users & Devices as shown.

image

You can revisit and make changes to your policy at any time by navigating to it and selecting it.

The options at the bottom of the menu on the left above: Device status, User Status and Per-setting status will again give you a summary of how this policy has been applied to devices.

Once we have all this in place we can now start joining actual devices to this environment so they can be manged. When we do that, they will be checked against the compliance policy and then have any configuration policies applied.

I’ll cover the process of adding devices to this environment in an upcoming article.

Setting up an iOS Intune device compliance policy

Once you have added an Apple certificate to allow device management for iOS as I have detailed previously here:

Adding an Apple Certificate to Intune

the next step in the process to get your iOS device managed is to create a specific iOS compliance policy in Intune.

A compliance policy is basically a set of rules that the device must follow to be considered compliant. If the device fails these rules then it is considered noncompliant and you are able to take action on that such as excluding it from connecting to your corporate data. Compliance for all devices is checked regularly.

image

To create this compliance policy you’ll need to login to the Azure portal and navigate to the Intune service. Once there, you’ll find an option in the menu Device Compliance as shown above, that you’ll need to select.

image

You’ll then need to select Policies on the left and the Create Policy option from the menu on the right that appears as shown above.

You may also see number of other existing policies here for different platforms. Note, that it is possible to have multiple compliance policies for the same platform if desired.

image

You’ll now need to give the new iOS compliance policy a Name, Description and select the Platform as iOS as shown above.

You’ll then need to select the Settings option below this to configure compliance rules. When you do so another blade will appear on the right with four categories: Email, Device Health, Device Properties and System Security as shown above.

image

You can configure as many options as you like here but I’m going to cover what I consider the basics for iOS compliance.

In Device Health, set Jailbroken devices to Block as shown above.

image

In System Security set the Password options as shown above.

Make sure you select OK at the bottom of each setting to update your preferences.

image

If you go into the Actions for noncompliance you’ll see there is currently a default option to Mark device noncompliant.

image

You can add more actions here, to Send email to end user and/or Remotely lock the noncompliant device if you wish.

When you have finished making your change, ensure that you Save the policy.

image

Now that the new iOS compliance policy has been created you’ll need to apply that policy to a group of users. To do this, select the policy you just created from the list of compliance policies. Then select the Assignments option from the menu on the left.

It is probably easiest to apply this new policy to all users but you can certainly select a group of users as well as exclude user if you wish.

Once again, when you have made you selection, ensure you Save any changes to have the policy applied to these users.

image

When devices connect to the tenant, they will be evaluated to be compliant or not. When this occurs, you can again examine the options at the bottom of the policy to see the device status as shown above. This will tell you whether connected devices are compliant (here they are).

image

You can also get the status by user, because remember, some users may have multiple devices.

image

Finally, you can also examine the per-setting status. This is handy if a device has failed compliance and you want to know exactly what setting(s) have caused this failure.

image

You can also see the compliance by examining the individual device in Intune as shown above.

You’ll see here that there is in fact a default compliance policy as well as any your have created.

Selecting the Built-in Device Compliance Policy will show you its settings like so:

image

Basically, the Built-in Compliance Policy simply checks whether device is active, the user exists in the tenant and another compliance policy has been assigned. Thus, the device won’t be considered compliant by default until we create at least one compliant policy for the platform.

image

If you instead select any of the custom compliance policies that you created you will see whether each individual setting is considered compliant in that policy as shown above.

So, creating a device compliance policy is important when we wish to use Intune to manage devices. You need to create a compliance policy for each platform with the settings against which devices will be continually checked. This will ensure that devices connecting to your environment maintain the settings you desire.

The next step will be setting up device configuration policies to actually configure how the device operates. That will be covered in an upcoming article.