TwistedHelixis

Found more info on the same page.... Enroll a Windows device Sign in to the Windows 10 device. Open https://deviceenrollmentforwindows.googleapis.com/v1/deeplink in a Chrome or Edge browser. Confirm that you want to switch apps. Enter the Google email address you want to enroll the device with. Click Next to start device enrollment. Sign in to your managed Google Account. If you get an error during enrollment, review the requirements. So I believe, even though my users along with their Windows devices, (some home personal devices) are listed in endpoints > devices and have approved for the status, they are not actually enrolled, which would then mean any Windows settings I deploy from the root OU should not apply to any of their personal devices as I wouldn't have carried out the steps above to enroll them. Does anyone else agree? Would be great if someone is already managing windows devices without GCPW installed could answer.

I might have stumbled on the answer. At he bottom of one of Googles support pages is the following.... And it only lists Windows devices I have ben testing GCPW on. So what I now need to workout is, does making a Windows setting change in Google Workspace, only apply to devices that either have GCPW installed or Enhanced desktop security setup? I really hope this is the case

So, I think one of the issues for me is, all these different settings have been listed in Google Workspace since it got created, some enabled some disabled. Its only after adding our new upgrade license that all these other settings might now have an effect. So, this throws up more questions for me then. If I look in Devices > Mobile and endpoints > Devices, I currently have a load of users and devices listed. For example teacher1 is on OS Windows 10. Are you saying I can also manage these devices for things like admin permissions etc even though they do not have GCPW installed? Edit - If this is the case, what happens if a teacher logs into their email from their home laptop and I have (Devices > Mobile and endpoints > Windows settings> Account settings) set to delete the local admin account, will this delete the local admin acc on their personal device?

The only reason I am not sure about the Windows Device Management policy is that Google mention the following.... If this only effected devices with GCPW installed, I wouldn't worry about putting it in the root OU, but 'some apply only to devices under Windows device management.' is not very helpful.I would prefer it to go in the root OU if possible, but I am a little concerned that if I do, its going to have some bizarre knock-on issues for our current Windows devices. Am I reading more into this than I should / worrying over nothing?

Thanks for your help with this. I am so close, just want to make sure I have everything lined up Just a few more questions and I think I might be there. do you have device approval Turned on (requires admin approval), or tuned off, so the devices auto approves? If so, is that at root OU or spacific OUs Do you have Windows device management enabled on the root OU, or specific OUs?

Sorry, another question.... Do you have Windows device management applied to the root OU, or specific OUs?

Also, do you have device approval Turned on (requires admin approval), or tuned off, so the devices auto approves? The reason I am asking, in my testing each separate teacher needed approving for each separate laptop. So if teacher A logs onto 2 laptops '1 & 2', they would need approving, even if a completely different teacher had already been approved on laptops 1 & 2. If it asked for approval just once per device that would be OK, but I can see things getting a bit OTT.

Thanks, that is good to know. Another questions, if that is OK.... Do you leave a default Windows local admin user account on the machine, or remove that and rely only on your “Administrators” OU

But.... What happens when one of your teachers leaves and you delete them from the Workspace Admin, if they are the main settings user on a device, doesn't that device become unusable? EDIT - Changed usable to unusable

@HyperTech EDIT - Just read your post above.... So the way I currently have this setup...... GCPW Windows device OU - With main setup user in this OU - Also has the custom (OMA-URI) policies applied (changing these settings also changes them for users that have logged in from the Staff OU) Staff OU - with 3 test teachers - Also has the main Windows settings applied (admin or standard user, Windows update, Bitlocker etc) During my testing the main user can log onto any number of clean Windows devices and set them up, then teachers 1, 2 and 3 can also log into that device and they will get the main Windows settings applied (admin or standard user, Windows update, Bitlocker etc), along with the custom (OMA-URI) policies. HyperTech, what happens when one of your teachers leaves and you delete them from the Workspace Admin, if they are the main settings user on a device, doesn't that device become unusable?

This is not the case in my testing. I log in with my first user, log out then the teacher logs in, they are then able to sign in to Chrome browser and Google Drive for desktop with their own account. That being said, SSO to Chrome browser is not working for me in my testing so far and was mentioned as not working for others in another post. Perhaps when it gets fixed, ill then have an issue.

I have been playing around with GCPW for a few weeks now. Am I right in thinking GCPW can only deploy custom (OMA-URI) policies at the computer level, not user level? Am I right in thinking its best to have a single GCPW setup user in Google Workspace, that is used just for deploying GCPW to all Windows devices. I read the first user to login to a Windows device running GCPW becomes the 'settings' user. All device / user settings are effectively deployed from the first account logged on. I guess if this is the case, I definitely wouldn't want to delete this account, of have random staff / pupils logging in first. Thanks

I have 2 schools with external support and 2 with Arbor support and I find Arbor support to be far better.

Thinking about this a little more, there probably isn't any 'device based' policies for Chrome browser. I think they are all user based anyway. Ill check when I am at a computer next

I don't have any Windows devices enrolled yet, so not really sure. We do have staff and pupils, so we might want different browser settings for those groups. Soon I'm going to be setting up GCPW, users will log into Windows using GCPW, which (when its working) should automatically log that user into Chrome browser. Its not clear to me if the Chrome Browser token OU is anything more than just that. if I enroll using a token in OU 1, and my users are in OU 2 & 3 does that mean I can set 'user' policies for OU 2 and 3, but only 'device' policies on OU 1? Or are device polices also in the same OU as the user that is logging in on to that device, or something else? On the page where it lists the Enrollment tokens, it doesn't say anything about managing devices from that OU or applying policies to that OU. Obviously, if the Token OU does also have an impact on which policies can be applied, then at the very least it probably makes sense to have 3 different tokens applied to 3 different OUs, Admin, Pupils and staff. I just need to know if the token OU, becomes the device OU and can have different policies applied.

So, I went with a single token in a new OU. If this is wrong, post back please.

We are just a small primary school. Is it a good idea to have separate tokens for staff and pupil OUs?

When setting up Google Chrome Enterprise Browser, is it best to create a single enrollment token for the entire domain, or separate tokens for each OU? If one for the entire domain, should I create an OU just for this task?

@dhicks just logged in to Windows using GCPW and my yubikey key as the 2 step.

Is that still the case. I have been watching a videos about setting up GCPW (been watching loads of these lately, lol) and I seem to remember in one they used a fido style usb key. Possibly wrong. Ill rebuild my test Windows VM and see if my key works.

Back then they were using Redstore backup & Windows server backup, depending on the school. Both worked without any issues. Now I help out at a few local primary schools. Most of the school files are in the cloud, so local backup is not such a big issue anymore. They also have zero money to spend on IT. All DCS I manage now are VMs, so this makes backing up and restoring much simpler. I use the schools old server (rather than chucking it out), and configure that as an ISCSI host. (ISCSI is built into Windows, just needs enabling) The main server is a Hyper-V host and has 2 VMs, DC and Data. On the main server I use ISCSI initiator to connect to the old server. The server sees this just like it would an external drive. WBS backs up both VMs to the ISCSI (old server) Every Saturday the backup is copied off to an external drive. I have 3 external drives on rotation. To restore, I mount the backup on a different server that is also running hyper-V and WBS, run Windows restore and the DC and Data VMs will be listed in Hyper-V ready to be turned on and tested that they work. I do a test restore of both the DC and Data servers a few times every term.

Still playing around with this, so a few things I have noticed... The installer sometimes misses adding reg keys, especially the domain locking one. So I might just create a script that adds the correct reg keys. Also, what is the point of having devices sent to 'Device Approvals'? The device I am testing with has not been approved (this time), but is still getting all of its policies and settings applied from Workspace. Still not managed to get the one thing I actually wanted working, auto log into Chrome Browser.

Think I might give up on this and get the users to login twice

So, I am still no further on with this. I cant seem to find this setting in our Workspace > Chrome Browser settings https://chromeenterprise.google/policies/#PromotionsEnabled Also But under that policy it says that disabling this policy the user cannot sign in to the browser and use account-based services. In this case browser-level features like Google Chrome Sync cannot be used and will be unavailable. Which doesn't sound right. Last question. Should logging into GCPW also add the browser to the Chrome managed browser listed in Workspace? Currently we are not using the managed browser system. Or do we still need to generate a token and deploy that independently?

Our entire county (almost all primary schools) have only one DC in each school. It only takes 10 - 15 minutes to restore from a backup and you don't have to worry about authoritative restores, tombstones entries or any of the extra Windows updates or DC sync issues. Hell you can even get away with in-place upgrades if you want, but I wouldn't recommend that on multi DC setups. Just make sure you have plenty of backups and they have been tested recently. I don't work for them anymore, but they have over 200 schools, so that's about 200 single DC systems all like this and in the 9 years I was with them, it was never an issue. The only people saying its an issue is MS, who want everyone to have thousands of servers.