Recently I migrated a customer from old devices to new Samsung devices. Both are enrolled using KME . The customer experienced they were not able to use Samsung Smart Switch after the new devices was enrolled and setup. That was a requirement from them, that their users needed to be able to migrate data from their old devices to their new devices.
We can always discuss if this is a good idea or not, anyway this was a requirement and here is the fix 🙂
A cool feature of Azure AD is Access review. It can be used for many things to control Azure AD group membership. One of the things I will be using it for is to control licenses and help to provide self service license management.
With Access Review we can control how often the users or owners are prompted to re-validate if the still need access to the group. This can be weekly, montly, quarterly or yearly. Once this period is over the users will be prompted via email to review their access to the group. We can even control what behavior will happen if the fail to do so.
As we know, in order to deploy apps with Intune on macOS the app needs to be a signed .pkg file wrapped into a .intunemac file.
From Adobe Admin console we can create a pkg file containing the Adobe CC app or other Adobe apps if needed. Unfortunately this file is not signed, and multiple forum threads confirm that signing them is not supported.
So how do we get around that? I was searching around to find a proper solution. I couldn’t find anyone who had come up with a solution, so I decided to find one my self. What if we don’t sign the Adobe CC pkg file it self but wrap it into another pkg file and run the Adobe CC pkg as a postscript? I did that and it’s actually working!
Disclaimer: I’m by no means a macOS guy, I’m a Windows guy and have always been :-). There might be things in this post that can be done smarter or in another way – if so, please let me know.
As stated on docs.microsoft.com, in order to distribute apps to macOS, they need to be in .pkg format and converted to the .intunemac format. Furthermore the .pkg file needs to be signed with a Apple Developer certificate.
Quote from docs:
The .pkg file must be signed using “Developer ID Installer” certificate, obtained from an Apple Developer account. Only .pkg files may be used to upload macOS LOB apps to Microsoft Intune. Conversion of other formats, such as .dmg to .pkg is not supported.
But what if we need to distribute an app there’s is not in the AppStore or is not in a signed .pkg file? Then we’ll have to repackage it with a packaging tool. I’m using an app called packages. Let me show it and explain.
Today my colleague (who have been working with SCCM for the last 15 years) asked how to handle USB dongles when they are shared between multiple Surface Pro devices in a staging facility. I was a bit surprised that he didn’t know, so I thought I’d put together a quick post about it, even though it’s pretty old news 🙂
By default, if we want to install multiple languages of Office 365 ProPlus on the same device, it is only possible if we create one package with all the desired languages. This is also the best practices from Microsoft on how to deploy additional languages with Office 365 ProPlus.
But what if we want to have one package for every language?
I know the same can be achieved by letting Office setting the install language to follow the OS language, but if the OS is always English and not localized, this doesn’t help.
An example could be if we always install English Office for all users, but want to provide the users an easy way to install another Office language. Or if we simply want to minimize the footprint and diskspace, by only installing the desired language or let the user decide what language of Office 365 ProPlus they want.
This can be done if we create the Office package as a Win32 app in Intune. Because we can specify Detection Rules, we can specify a different rule for each language. Using this method also lets you add an Image that fits and looks better in Company Portal. I’d recommend using the following image:
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
I had a customer who called about a single user had issues with setting MFA up to use text, Phone call or even Microsoft Authenticator via. http://aka.ms/MFASetup. The call or text message was never received. In the Authenticator App, when they scanned the QR code, they got the following error pop up:
“Activation failed. Make sure that push notifications are enabled on the phone and your Activation Code is not wrong, expired or formerly used.”
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)