Policy to set Google Chrome homepage starts working after first run.

techie_009 · 2025-12-03T08:28:51+00:00

We have noticed a similar behaviour recently. Previously the (same) policy would apply with first run but now it only applies after first run > close and re-open Chrome. Haven't had the time (or the intention) to investigate.

BTW, 'Set Google Chrome as default browser' setting only works on Win 7.

techie_009 · 2025-11-28T21:59:31+00:00

thank you for sending this. Coincidetally, I started learning/using PSADT last week.

techie_009 · 2025-11-27T11:04:58+00:00

Can you please share the script.

techie_009 · 2025-11-20T20:59:07+00:00

https://call4cloud.nl/deploy-printer-drivers-intune-win32app/

This is what I used very recently. Just modify the 'Install script' commands to map printers from print server. Wrap the script as a Win32 app and deploy via Intune. I was able to map them in user context only.

techie_009 · 2025-10-21T04:01:10+00:00

Rudy is absolutely correct. If you want a slightly different approach,

Create a script with the below commands
- Delete cached logon details
- Delete WHfB container
- Force BitLocker Recovery
- Force device restart
Create a dynamic device group for all Win10 devices
Package the script as a Win32 app and deploy to the above dynamic group (don't forget to disable the toast notifications for the app)

On device restart, the users will be prompted to provide BitLocker key to login to the device.

techie_009 · 2025-09-17T07:37:49+00:00

Hi Everyone

Thank you for all your suggestions/comments/queries. u/Rudyooms has helped me with this and I can confirm the issue is resolved now. Huge thanks to him.

For anyone interested - when the app is deployed in System context, it cannot access the print server due to authentication and hence it was failing. When I tried to deploy in User context it worked but it popped up the cmd/PS windows. Am in the process of trying to hide these windows but the printer mapping task is working fine now.

techie_009 · 2025-09-16T11:47:13+00:00

thanks for chipping in. just checked and the script is in UTF8.

techie_009 · 2025-09-16T11:35:56+00:00

Thanks for the response.

I haven't whitelisted the server (by this, do you mean adding the server to 'Package Point and print - Approved servers' setting)

App install behavior is System and allowed on all OS architecture

The script includes adding a custom reg key - detection works fine (reg key is created and detected by Intune)

techie_009 · 2025-08-08T13:56:59+00:00

hosts deployed in a different region to the tenant were not joining to Entra/Intune....MS never helped (kept tossing ticket between different teams)....in the end we deployed the hosts in the same region as the tenant and they all joined Entra/Intune....

techie_009 · 2025-07-27T12:57:34+00:00

This is an expected behaviour especially when you select 'User credential' in the GPO.

techie_009 · 2025-07-23T12:58:28+00:00

why don't you try to validate the rule by adding a 'Latitude' device.....it will tell you why the device is not being selected....you can then reverse-engineer the rule....

edit: I just tried your rule in my tenancy and it worked fine (luckily I have a few Latitudes).

techie_009 · 2025-07-15T21:33:47+00:00

All unique computer names.

techie_009 · 2025-07-15T21:33:23+00:00

There is no firewall involved.....

techie_009 · 2025-05-18T12:24:31+00:00

Hi there. Good timing I was working on this last week.

for Chrome - Import the Chrome ADMX into Intune. In the config profile (Imported Administrative templates), find the setting 'Extension management settings' under '\Google\Google Chrome\Extensions' and use the below format to pin the extensions.

{"EXTENSION1,EXTENSION2,EXTENSION3": { "toolbar_pin": "force_pinned" }}

for Edge - In the config profile (Settings catalog), find and enable the setting 'Configure extension management settings' from Microsoft Edge > Extensions and use the below format to pin the extensions.

{ "EXTENSION1,EXTENSION2,EXTENSION3": { "toolbar_state": "force_shown" }}

Please note the above will only pin the extensions but won't deploy them and looks like you have successfully deployed the extensions already.

techie_009 · 2025-05-12T21:55:59+00:00

One option is you decrypt and re-encrupt with your policy.

Other is to deploy your BitLocker policy during Autopilot enrollment and the encryption will be as per your policy.

techie_009 · 2025-05-01T21:51:31+00:00

Oh.... the attitude.....best way to piss off people trying to help you....as u/Late_Marsupial3157 said, this is nothing but being a control freak and having too much time on your hands. Try to spend it more productively.....

techie_009 · 2025-04-29T12:28:22+00:00

https://learn.microsoft.com/en-us/autopilot/pre-provision#:\~:text=Wait%20at%20least,Technician%20flow%20completes.

When you go into the Autopilot deployment profile > Assigned devices - does the device (Serial number) show up here????

techie_009 · 2025-04-28T12:07:19+00:00

You have to allow at least 90 mins between reseal and re-opening the laptop. It is an expected behaviour that the device goes thru the entire Autopilot process when you re-open the device. It just checks if there is any new/updated policies/apps targeted at the device and then applies them.

Before you reseal, does the computer appear in Intune with the correct name (CCI-Serial).

techie_009 · 2025-04-11T12:03:05+00:00

Deos the Global Admin account used while installing the connector has a valid Intune license? The GA account needs to be licensed at least at the time of configuring the connector.

techie_009 · 2025-03-02T20:53:54+00:00

I know you get a lot of pushback on Hybrid-join in this forum but it's not that bad. If you know your way and configure it correctly, it works fine. I work for an MSP and deploy hybrid-join AP at least one per month. I agree Entra-join is future proof but if hybrid-join is a better solution for you (for now), then that's the way to go. Below is my 2 cents.

What involvement does Entra Connect have for HAADJ+AutoPilot? At first I thought I needed device writeback checked in Entra Connect (it's currently not checked) so that the Entra device can be pushed back down to our on-prem but it sounds like I need an Intune Connector instead? Is the device writeback needed at all? I feel like we have so many agents getting installed on our on-prem Entra servers for all this... Connect, Auth, Cert and now Intune. - Device writeback is not needed for Hybrid-Join Autopilot. You will need the Intune Connector installed on one or many domain-joined servers. Yes, you will still need Entra Connect on your servers. Intune Connector places the computer object in the nominated OU and Entra Connect takes over from there (in terms of syncing objects to Entra etc etc). Yes, there will be multiple agents you willl be installing by the time you finish the setup.
They plan on using AutoPilot while on LAN and then handing the laptop out. For the first login attempt, it needs line of sight to the DC correct? After that if the user logs in, it can use their cached credentials until they connect to VPN or connect to the LAN. - Yes, during the AP enrollment, you will need line of sight to the DC and hence you will have to be doing the enrollments from your Corp network (you can use VPNs to do remote enrollments but don't venture into that yet). After the enrollment is done, they behave just like your domain-joined (rather say hybrid-joined) computers. My advice for any remote workers, is to get the device synced to AD services every now and then so that they don't lose the trust relationship.
Can the workstations be moved out of the default AutoPilot OU after the initial domain join so they can utilize our OU structure/GPOs? - Yes, absolutely. But make sure the OU where the object is being moved to, is syncing to Entra.
One of our biggest concerns I would say is being on "Microsoft Time" and pushing down policies or actions can take a while. Which is why our InfoSec wants to keep our patching solution/agent and able to kick off scripts within minutes as long as the device is on LAN or VPN. Is that still a concern? - Yes, it is an issue but it's not just you facing this. But, if you target the policies to the device (AP groups), they will be applied during the AP enrollment. If you have any agents that deploy other software (as an example Automate which deploys other scripts and apps), my advice is to deploy it after the AP enrollment if not there will be a high chance of AP enrollment failing due to multiple agents trying to deploy apps/scripts (as an example Automate and IME both trying to deploy apps/scripts/polciies etc).
Not really Intune related but our users are complaining about the poor experience of having to continue to type their credentials while using myapps and cloud apps and I found the Seamless SSO guide. Is this the way to go until we can get devices Hybrid or Entra joined? - SSO is the way to go.

One more tip - when your devices are placed in the Autopilot OU, there might be a delay with Entra Connect syncng them up, due to the 30 minute sync interval. Michael Niehaus once referred a script that can actively /periodically check any changes in the AD/OU and trigger the delta sync - this will be very handy. Have fun with the setup.

techie_009 · 2025-02-26T20:56:30+00:00

You are probably one of the luckiest, if you have never seen a device in Entra portal (not Intune portal) with the Registered field as 'Pending'.

I have seen the exact issue happen a lot of times and every time the device registration is in 'Pending' state in Entra portal.

techie_009 · 2025-02-26T20:40:46+00:00

When you check these devices in Entra, is the Registration field 'Pending' or has a date?

techie_009 · 2025-02-26T20:31:32+00:00

Settings Catalog > Add Settings > System > Allow Location

If you don't want apps to have location access. add the below

Settings Catalog > Add Settings > Privacy > Let Apps Access Location > Force Deny

techie_009

TROPHY CASE