Everything can be done automatically, as long as you configure it manually… 8-)
Do you need a simple, but yet effective way of forcing people into updating iOS on their company enrolled Apple devices? Simply block access to company resources if iOS is not up to date. Here is how you can do that using Microsoft Intune and Conditional Access in Microsoft Azure.
UE-V is not something new, but when combined with OneDrive Known Folder Move, Enterprise State Roaming in Azure and OneDrive as the storage path for UE-V, you will find yourself with a very solid solution ensuring roaming of end users data and settings.
I have previously shown you how you can enable OneDrive KFM with SCCM. This time, I’m going to show you how you can enable UE-V during OSD with Configuration Manager, and how you make sure those settings are stored in OneDrive. I hope you can see the pattern here: No on-premise file share for UE-V settings – everything stored in the users OneDrive.
More Configuration Manager 1806 and more awesomeness. 1806 gives us additional improvements to the Cloud Management Gateway and removes the need for PKI in your environment. With these improvements, it has never been easier to setup the CMG. In this post I will walk you through the exact steps I went through in order to successfully deploy the CMG in a HTTP only environment.
Again, continuing the Co-management and flipping the switch journey, and moving the brand new Device Configuration workload to Intune MDM. This is the latest addition to the co-management world introduced in Configuration Manager 1806 (released 2 days ago at time of writing) and it’s absolutely amazing.
This means we finally (almost) can ditch group policies altogether and do our device configurations with Intune MDM. I will give you how to and an excellent example in this post. Read on. 🙂
Just like I did with SCCM 1802, where I went through the exact steps for upgrading Configuration Manager Current Branch to the latest and greatest version, I’m going to do something similar in this post with 1806.
Nothing really changed, but I know someone would fancy to have an A-Z guide to walk them through the process, and as of such, I here give you the exact steps I went through to upgrade my environment.
This will be something completely different and new coming from my end. So please be aware; a lot of strong coffee is potentially needed. That be, because I usually talk about how to do something technically around Configuration Manager and Microsoft Intune, or something technically related to those topics, and the typical reader would probably expect content in that context.
This time I’m going beyond that. “Why?” you may ask. Because I felt like giving back with a topic and content that I know that can make a difference. Not just limited to a specific technical topic, but as a whole, make a difference on how one will succeed in general with Configuration Manager and Microsoft Intune (and possibly other stuff too).
I believe in helping and promoting others, and as of such, I will give you 5 (and possibly some unique) advice on how you can improve and strengthen your SCCM and Intune knowledge. (No guarantees though, but the bullets mentioned in this post helped me a lot)
Back in May i did a post on how to leverage Powershell App Deployment Toolkit and Configuration Manager to in-place upgrade to Windows 10 1803. Find the post in the link below:
Today I’m providing you with an update on the topic and giving you an updated version of the content. Note that the basic instructions for using all of this, is still found in my original post above.
Users with Office 365 administrator roles are very much sensitive users, and besides protecting them with various features such as Conditional Access and MFA, it might be interesting to know if someone tries to brute force or guess their credentials.
In this post I will walk you through how you can setup a policy in Cloud App Security, that automatically sends you an e-mail, if someone fails to provide the correct credentials for users with any Office 365 administrator role assigned.
Following up on my promise and continuing this mini-series of blog post, where I’m trying to address some of the basics of Configuration Manager. This time, I’m going to give you an example of how you can to add computers to groups in AD (Active Directory) during the deployment of Windows using a web service and Powershell.
I have previously given a few examples on use cases for Conditional Access, and I admit, for the Conditional Access newbie, the options available can seem daunting. So how about a very simple scenario, where access to company resources are blocked, if not coming from a trusted IP?
Imagine service accounts running some Powershell scripts for automation in your Azure/O365 tenant or other accounts who are never meant to be used outside of your organization. Simply block those from authenticating in Azure/O365 if not coming from your headquarter public IP. This is how you can do just that, using Conditional Access.
