User Profile
joel_grangier
Brass Contributor
Joined Jan 16, 2019
User Widgets
Recent Discussions
Re: Installation of new Win32 app to existing Intune Shared PCs not installing, but installs on rebuild.
reggie_1968 : Have you tried to set the "SkipUserStatusPage" to enabled? We had already a similar issue. As the "Account Setup" step has never been completed due to your construct of a shared device without user affinity, the "Intune Management Extension" is waiting (for ever) for this step to be accomplished before installing additional Win32 apps. You could try to deploy the following OMA-URI setting to your shared devices: ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage https://docs.microsoft.com/en-us/windows/client-management/mdm/dmclient-csp5.4KViews1like2CommentsRe: Installing .MSI and .EXE based applications as part of Autopilot
Rudy_Ooms_MVP I'm just speaking about a professional solution/concept, which would never cause any issue. You never know what the future holds... You could also have this issue outside of the ESP process (meaning when the user is already logged on and has an interactive desktop). In that case, the installation of the impacted apps will be delayed. These apps will be available in worst cases only the next day... But anyway, these are just recommendations and everyone can do what he wants 😉29KViews0likes2CommentsRe: Installing .MSI and .EXE based applications as part of Autopilot
Chris-Yue I would really not recommend to have a mix of MSI (Line-of-business app) and EXE (Windows app (Win32)). The OMA DM agent can starts an MSI installation and simultaneously the Intune Management Extension plugin can start a Win32 app installation. If your Win32 app would install an MSI as well (embedded), this will cause an issue because it's not possible to have multiple instances of Windows installer (in relation with TrustedInstaller) at the same time. This is also documented in the following article (See Note): https://docs.microsoft.com/en-us/troubleshoot/mem/intune/understand-troubleshoot-esp#device-setup33KViews0likes4CommentsRe: OMA-URI Settings to Allow users to change time fails!
SamSONACA At this time, there is unfortunately no automated way to perform this. You can use the https://docs.microsoft.com/en-us/mem/intune/configuration/group-policy-analytics as an helper. You have still to create the desired configuration profiles manually, for the most policies that you currently have. If your goal is migrating your current on-prem environment in the cloud, you should consider to not do a 1to1 migration of your GPO's. There are for sure some policies which should no more be needed, or which doesn't make any sense anymore. It's the right time to perform a cleanup action on your policies ;-).5.6KViews0likes0CommentsRe: OMA-URI Settings to Allow users to change time fails!
Hi SamSONACA, Yeah, the "Policy CSP - UserRights" isn't really well documented. This is how I've used it in my test environment: OMA-URI: ./Device/Vendor/MSFT/Policy/Config/UserRights/ChangeSystemTime Data Type: String Value: *S-1-5-19*S-1-5-32-544*S-1-5-32-545 As mentioned in https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-userrights, it is better to use SIDs, because strings are localized for different languages. For reference, see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab?redirectedfrom=MSDN. Now, you have to be careful with the special character . Johan Arwidmark has already well explained in https://deploymentresearch.com/configuring-user-rights-policies-in-intune-via-custom-profile/ how to handle this. The real delimiter is:  It has to be converted to: In MEM, it will be displayed like this: Im my case, the end user with standard user rights can only change the time through the "timedate.cpl". The shield of UAC is still displayed, but the end user is nevertheless able to change the time:5.2KViews0likes2CommentsRe: Intune | Powershell Script
Hi AnuragSrivastava; Yes, the system context will make the script runs with admin privileges. The "Local System" account is used and this account has always admin privileges on a device. But in that case, the script will be executed in an other context as the one of the logged on user. So, if you want, for example, to uninstall an application which has been installed per-user (in the user context), you have to adapt your script accordingly.15KViews1like0CommentsRe: Deploy EXE as Admin
StuartK73 If your Intune package needs admin privileges to be installed, you should install it under the system context, by selecting the correct "Install behavior". If you have selected "User", the installation will run in the context of the logged-in user and the UAC will pop-up if it's activated. If am I understanding your case correctly, I assume that the user is not admin on the device...4.5KViews0likes1Comment
Recent Blog Articles
No content to show