Runas Global Administator Azure AD account or Add Office 365 Azure AD Account To Local Administrators Group
Wednesday, June 5. 2019
runas /user:AzureAD\email@example.com cmd.exe
For adding Azure AD account to local admin group simply run:
Net local group Administrators /add "AzureAD\
Monday, May 27. 2019
Just a quick step-by-step guide on how the configure Android Zero Touch with Intune.
Why do we want to use Corporate-owned, fully managed user devices? In order to give the user an out-of-box experience that automatically enrolls devices into our MDM solution, just like Apple DEP but for Android Enterprise devices. Also, it gives a less confusing user experience, as we only have a work profile and not a private AND work profile, like we do with personal owned android devices.
Of course this is still a preview feature in Intune, and context is subject to change.
A compatible device running Android Oreo (8.0) or Pixel phone with Android Nougat (7.0), purchased from a reseller partner
A Login to the Android Zero Touch portal provided by your reseller ( https://partner.android.com/zerotouch)
Enable Managed Google Play
Create Android Zero Touch Token
Create and Android Zero Touch configuration
Preparations in Intune
First we need to create an Enrollment Token in Intune. If you haven’t used Managed Google Play Intune yet, this need to be configured too.
Monday, May 27. 2019
Quick and simple tip on how to get a Logon script like experience with Intune. On Azure AD joined devices, there’s currently no option to create Logon/Logoff or Startup/Shutdown script like we can with GPOs. I had a customer that needed a solution to start a command file as admin everytime the user signed on to the device.
There’s a workaround – Use Scheduled Tasks to create tasks that runs on Log On, and runs with Administrator rights / Local System if needed. It’s a very simple Powershell script, that created a scheduled task:
Create the scheduled task
Runs at Logon
Runs with Local SYSTEM account
Runs a command specified (in this example it runs a .cmd file that requires administrative rights. The .cmd file is already present on the devices – a software vender has placed it here)
Full script is located here:
# Specify the command and argument
$action = New-ScheduledTaskAction -Execute 'cmd.exe' -Argument '/c C:\Temp\start.cmd'
# Set the trigger to be at any user logon
$trigger = New-ScheduledTaskTrigger -AtLogOn
$STPrin = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount
# Create the scheduled task
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "StartCMD" -Description "Start the CMD as admin" -Principal $STPrin
Configuring it in Intune
To make it run on the devices, go to Microsoft 365 Device Management portal (https://devicemanagement.portal.azure.com).
Go to Device Configuration and select Powershell scripts:
Give the script a name.
Browse and find the .ps1 file.
Click Settings and make sure “Run this script using logged on credentials” is set to No.
Click OK and then Create.
Now we need to assign the script to an Azure AD group containing the devices or the users on which the script should run.
The script will be created on next client sync, and is located in the Task Schedule root folder:
If we at a later point need to change or delete the scheduled task, it can be done easily with a simple powershell command.
## Delete the scheduled Task
Unregister-ScheduledTask -TaskName StartCMD -Confirm:$False
Put that in a .ps1 file, and create a Powershell script in Intune as we did above. Unassign the initial script, and run this instead.
Changing the Scheduled Tasks / Advanced scenarios
While it’s is possible to change the script and upload a new script, existing devices that have already run the script, will not run it again, even if we change the script.
There’s multiple options here, two of them – which are kinda related:
Saturday, May 11. 2019
Quick brain dump today. One of our customers recently reached out with an issue where a policy for Windows 10 wasn’t applying correctly, and we were returning a very unhelpful error message “-2016281112 Remediation failed”.
Unfortunately, the Remediation failed error message is all that is returned by the client when we issue the SET command on the OMA-URI’s required to configure the target setting. We’re partnering with Windows to improve this experience, so watch this space. But for now, we have to settle for what we have.
So what are the next steps in troubleshooting this error?
Luckily, Windows has a pretty good diagnostics channel in everyone’s favorite Event Viewer (eventvwr).
So first, open up eventvwr.msc from Run.
Next, browse to Application and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider. You’ll see two logs, Admin and Operational
Firstly, take a look in the Admin log. You should see some high level error messages which might point to an obvious issue. For example, here on my corp device I’ve got an error message for an app deployment via MDM.
This error obviously indicates an app is not being discovered as expected. I recon if I gave this a couple more syncs, the app would reinstall and all would be well.If the error messages in the Admin log are still unhelpful, we have one other option and that’s to enable Debug logging on the DeviceManagement-Enterprise-Diagnostics-Provider.
To do this, from the View menu in eventvwr, enable the Show Analytic and Debug Logs option. This will likely make your eventvwr window flash like crazy for a minute or two, but it’s enabling a bunch of extra logs and the UI doesn’t like it much.
Once enabled, you’ll now see a Debug log option in the DeviceManagement-Enterprise-Diagnostics-Provider. Now enable the log by right-clicking on the log and selecting Enable Log.
Now run a repro of your issue by running a Sync (Control Panel > Access work or school > Connected to Azure AD > Info)
In the debug log, you should see a bunch of verbose debug information about the sync and settings being applied.
And here you can see the Wifi URI being applied successfully. If there was an issue with the Wifi configuration, I’d get a much more helpful reason as to why the URI failed. I’m not seeing the error from the MDM MSI anymore, so it must have fixed itself on subsequent check-ins.
Thursday, April 25. 2019
In a modern managed environment we deal with highly mobile Windows 10 users. The MDM capabilities in Windows 10 allows enterprises to manage these devices even when distributed all over the globe. This is a great enhancement as we can configure and check compliance of devices everytime. But most advantages also introduce some disadvantages and these are the ability to effectively troubleshoot devices like we did in the past. Just walk by and have a look at the event log entries or grab some log files isn’t possible most of the time. Even remote sessions can be challenging, especially when dealing with different timezones.
It is possible to gather on-demand diagnostic log files from Windows 10 via the MDM channel.
Windows Insider or Windows 10 Version 1903 which includes the DiagnosticLog CSP in Version 1.4.
The procedure is very simple and can be broken down into a server part and device part which follows some easy steps. For the server part there are 3 steps:
The IT Pro specifies the data collection definition in form of a XML structure. The types supported here are: event logs, log files, command output, and registry
The IT Pro provides a provisioned cloud storage and a shared access signature (SAS) URI for the upload
The MDM server (in this case Intune) sends the data collection and upload URI to the device
The device part can also be broken down into 3 steps:
The Device evaluates the data collection XML via DiagnosticLog CSP and drops entries which violates privacy guardrails. Guardrails define allowed paths, commands, extensions, etc. – C:\Users\… is not allowed for example.
The Device gathers remaining data collection directives and puts them into a single zip archive labled with hostname and time stamp
The device uploads the .zip file to the provided cloud storage SAS URI
Finally we can access the storage account and have our data collection package available for download and troubleshooting.
Thursday, April 18. 2019
Windows Autopilot moves customers away from custom imaging and driver management, instead leveraging Microsoft Intune to transform a device into one that is ready for productive use. Intune supports a lot of different policies that can be used to configure the device, but in many cases there aren't any policies that enable configuring defaults. For example, what if you wanted to configure the Start menu layout, but wanted the user to be able to change any part of it?
Most of these types of customizations can be done via scripts, similar to the way that you did them when you were building custom images. But instead of baking them into the image, you now need to apply them to the device "just in time" - typically before a user signs on for the first time. With Windows Autopilot, we can leverage the Enrollment Status Page (ESP) to ensure that these machine configurations are made before the user signs in. But those capabilities vary by OS release:
Windows 10, version 1803 and above can leverage the ESP to block user login until all policies, certs, and device-targeted single-file MSIs (LOB apps) have been processed.
Windows 10, version 1809 and above adds the ability to block until Office 365 ProPlus has been installed.
Windows 10, version 1903 and above will have the ability to block util Win32 apps (installed by the Intune Management Extensions) and PowerShell scripts have been installed or processed.
So, you could just leverage PowerShell script to do the configuration steps that are necessary - but since few of you are deploying Windows 10, version 1903 broadly yet (not surprising, as it's not yet released), that would be rather limiting.
To do this in a way that works with Windows 10, version 1803 and above, you can take the same PowerShell script logic and embed it into a Windows Installer MSI; that MSI can then be targeted to a group of devices (e.g. All Autopilot Devices). As long as you have enabled ESP and configured it to be blocking, this MSI install will complete before the user signs in.
Since I suspect quite a few of you have never created a "hand-crafted" MSI with an embedded PowerShell script, I thought it would be useful to publish an example. You can find that example here:
Included in that example is a PowerShell script that performs the following customizations:
Customize start menu layout. By default it will apply a simple two-icon layout (similiar to the default one on Windows 10, version 1903, but without the Office app).
Configure background image. A custom theme is deployed with a background image; the default user profile is then configured to use this theme. (Note that this won't work if the user is enabled for Enterprise State Roaming and has previously configured a background image.)
Set time zone. The time zone will be set to the specified time zone name (Pacific Standard Time by default).
Remove in-box provisioned apps. A list of in-box provisioned apps will be removed.
Install updated OneDrive client per-machine. To support the latest OneDrive features, the client will be updated and installed per-machine (instead of the per-user default).
Disable the Microsoft Edge desktop icon. When using OneDrive Known Folder Move, this can cause duplicate (and unnecessary) shortcuts to be synced.
Feel free to download this from GitHub, customize it as you see fit, and then build your own custom MSI that can be deployed via Intune. The necessary instructions for creating (building) the MSI are included in the GitHub repository.
Intune Endpoint Proctection Policy Best Practises. STEP-BY-STEP GUIDE: USING INTUNE TO CONFIGURE WINDOWS 10 SECURITY
Thursday, April 18. 2019
Windows 10 includes a huge number of security settings that can be applied to protect your computers from ransomware, viruses, and other malware. Because Microsoft makes the deployment of these settings available through many different sources and because every business environment is different, these settings are not configured by default. There are many ways to configure these settings: your RMM, System Center, Configuration Manager, Group Policy, PowerShell, Local Policy, Intune, and even simply in Settings. Today, we will look specifically at configuring these settings using Intune. Microsoft now provides Intune in many of the Office 365 subscriptions so it has quickly become the most available method for small and medium-sized businesses, although most will not find this to be a self-service venture and will likely want to pursue professional IT assistance.
When you log into your portal, you’ll quickly find out that Intune has moved into Azure. Honestly, it’s about time. This will go a long way toward bringing Intune into a common set of standards. It’s been a moving target for too long.
Here’s what you need to do to configure Intune to enable Windows 10’s malware protection. The settings that follow can be improved upon or changed to meet your needs but should serve as a nice starting point
Thursday, April 18. 2019
1Use the ADFS to Azure AD app migration tool to analyze your current apps. This tool will quickly identify which apps can be migrated seamlessly and which require remediation (see figure one).
2Acquire deployment guides for the relevant apps. Many are published on the Microsoft app gallery, but if not, you can open a ticket through the third-party vendor who developed the app.
3Allocate appropriate time and resources to the high-touch apps.
4Migrate the apps that are ready to go for quick wins.
5Identify a test environment or plan a maintenance window to avoid moving large servicing app at peak usage.
Tuesday, April 9. 2019
In this post I will focus on deploying WiFi profiles with pre-shared keys (PSK) to Windows 10 devices using a custom device profile in Microsoft Intune. There are a few good posts about this topic already and various methods but I’ll try to consolidate all the info I found, walk you through this step by step and also give you some troubleshooting tips on the way.
Pre-shared keys (PSK) are typically used to authenticates users in WiFi networks, or wireless LANs. With Intune, you can create a WiFi profile using a pre-shared key. To create the profile, use the Custom device profiles feature within Intune. This article also includes some examples of how to create an EAP-based Wi-Fi profile.
Using a pre-shared key with Windows 10 causes a remediation error to appear in Intune. When this happens, the Wi-Fi profile is properly assigned to the device, and the profile works as expected.
If you export a Wi-Fi profile that includes a pre-shared key, be sure the file is protected. The key is in plain text, so it's your responsibility to protect the key.
Tuesday, April 2. 2019
onfigMgr admins have invested countless hours and effort in creating Task Sequences to perform various imaging functions in their environments. These are typically Bare Metal (New Computer), Refresh (Re-imaging of existing PC), and Replace (Migrating User Data to new computer). While there have been many enhancements to the Task Sequence engine over the years, the basic functionality and implementation of these mechanisms have largely remained static.
With the introduction of Autopilot, administrators now have a completely new method to handle these scenarios with a high degree of function parity between it and Task Sequences. While there are certain limitations to Autopilot as it exists today, these limitations shouldn’t preclude ConfigMgr admins from exploring Autopilot.
Thursday, March 28. 2019
Windows Analytics provides a key component in a modern managed environment. If we use Windows Update for Business we have no way of monitoring key performance metrics of our environment without Windows Analytics. Windows Analytics is based on an Azure Log Analytics instance which provides three key solutions.
Update Compliance to monitor Quality Updates, Features Updates and Delivery Optimization performance.
Upgrade Readiness is used to get insights into your app environment and to plan a mitigation strategy for successful feature upgrades.
Device Health is used to gather crash data to get proactive and resolve app and drivers issues in your environment.
To get the client data into the Log Analytics instance to let the Windows Analytics solutions provide you the insights we need to onboard our corporate clients. In this guide I will walk through the MDM settings set by Microsoft Intune. Keep in mind that these settings can also be controlled with GPOs which we will not show here. We will look at every setting and the pitfalls they may have and how to overcome these. This is a guide for corporate devices, for personal devices you might want different settings and more control for the user. In a corporate device scenario you take control over the settings.
Setting up Analytics
Tuesday, March 12. 2019
How to configure Android Enterprise – Corporate-owned, fully managed user devices mode with Microsoft Intune
How to configure an Android device in Single App Kiosk mode with Microsoft Intune
How to setup Android Enterprise – Corporate-owned dedicated devices with Microsoft Intune
How to Migrate from Android Device Admin (legacy) to Android Enterprise with Microsoft Intune
How to Enable Android Enterprise and configure Personal devices with a Work Profile in Microsoft Intune – The ultimate Step-By-Step Guide
How to configure Android Enterprise – Corporate-owned, fully managed user devices mode with Microsoft Intune
Tuesday, March 12. 2019
It’s now time for the last mode; Android Enterprise – Corporate-owned, fully managed user devices. And as the name of this mode indicates, this mode is for user based scenario’s. The enrollment process is more or less the same as with the dedicated device mode. The enrollment process also start with scanning a QR code. However, a user needs to enter his or her credentials during enrollment and all applications and profiles needs to be published user based (see also step 6: testing the results).
In this blog I will show you step-by-step how to configure the Android Enterprise – Corporate-owned, fully managed mode within Microsoft Intune. Note that by the time of writing, this mode is still in (public) preview.
Before you can start with the configuration of this mode, make sure you have the following in place;
Microsoft Azure tenant with Microsoft Intune up and running
Linked your Managed Google Play account with this Azure tenant
Android test device(s)
In this blog I will cover the following topics;
Step 1 : Create a Corporate-owned, fully managed user device Enrollment Token
Step 2 : Create an User Group
Step 3 : Publish Google Managed Applications
Step 4 : Configure App Protection Policies
Step 5 : Create a device restriction profile
Step 6 : Test the results
Let’s get started.
Tuesday, March 5. 2019
Office 365 Encryption for All
In October 2017, I wrote about the refreshed Office 365 Message Encryption (OME) functionality that was just showing up around that time. I noted that new features and better client integration made it easier than ever before to protect messages, even between Office 365 tenants and other domains. Now, Microsoft has introduced a new protection policy called “Encrypt-Only” (or just Encrypt) to encourage users to protect sensitive email more than it happens today.
Simple Encryption is not Always Simple
Message encryption is a very old concept and well-regarded technologies like Pretty Good Privacy (PGP) and Secure MIME (S/MIME) have been in common use for many years. You can use S/MIME with Office 365 or find a PGP plug-in for Outlook, but in both cases the configuration can be tricky and involve several moving parts.
Although Microsoft would not say that their aim is remove the need for Office 365 tenants to use S/MIME, PGP, or other third-party encryption, it seems likely that providing an out-of-the-box solution that can encrypt messages to any email address is a powerful hint that this is their direction. And given that Microsoft controls a large percentage of the clients that access Exchange Online, they can make the encryption/decryption process much simpler and better integrated than any third-party software can.
How to Encrypt a Message
As explained in the previous article, you protect messages by applying a rights management template. The template can be one of the default set created when a tenant configures Exchange Online to support protection, or one created and customized through the Azure portal to meet a business need. Azure Information Protection is included and enabled for all tenants with the Office 365 E3 and E5 plans. Clients connected to all E3 and E5 tenants can read encrypted messages without any configuration, but the tenant IRM configuration must be right before clients can initiate an encrypted conversation.
To encrypt a message with OWA, click the Protect button in the New Message window, then click Change Permissions in the message bar, and then select “Encrypt” from the set of available templates.
Monday, March 4. 2019
Hello everyone, today we have an article from Intune Support Engineer Leon Zhu. In this post, Leon talks about deploying MSI installer packages and how you can troubleshoot problems if the app fails to be installed on targeted devices. Leon has some really great tips in here so even if you’re like most people and never had an issue, I’d suggest giving it a quick read regardless. It will help with understanding how the overall process works, and if you do happen to run into a problem in the future, his tips will put you well down the path of getting them resolved quickly and easily.
Intune is a great way to deploy Windows LOB apps to PCs in your environment, and today I want to talk a little bit about how that process works and share some tips you can use to help resolve any issues you might run into.
Here in support, when we talk to someone having an issue deploying an MSI package it usually goes something like this: An app deployment profile was created for a Line of Business (LOB) app using an MSI installer package, however after assigning the profile to a group of users you find that some devices fail to install the app. When we see an issue like this, it’s usually caused by one of two things:
The MSI failed to download
The setup process for the MSI failed
With that in mind, if you find yourself in this situation the first thing to do is check whether the MSI has been downloaded. Downloaded MSI packages are stored in C:\Windows\System32\config\systemprofile\AppData\Local\mdm so take a look in there and see if you can find your MSI. Typically the size and date are good ways to determine which one is the package you’re looking for.
|© 2007 Fatshark all rights reserved | Design: Fatshark|