CHiLL

I've also lost access to my downloads and keys section, though it does still list our valid license agreements and I can see the list of product keys separately.

I don't know why, or for how long, but I've noticed our proxy bypass GPP rules aren't applying, but specifically just the bypass rules. In the IE10 rules, if I remove the check for 'Use a proxy server for your LAN', this setting it applied to the clients and they don't have the proxy set. If it it then checked again, the proxy is set. But regardless of whether I check the box for 'Bypass proxy server for local addresses' or not and specify entries in the Advanced box, these settings do not apply to the user. The check box for bypass the proxy server just remains unchecked and there are no entries listed in the Advanced box. It's not conflicting policies, but I can see I'm editing the winning/applied GPO. There is also no associated registry key for the user: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings] ProxyOverride"="" If I add that registry key in manually via GPP, then the proxy bypass is checked and the entries specified in the registry key are listed. I don't know why checking the box doesn't work, I'm at a bit of a loss at the moment.

We haven't updated the driver or made any modifications to the advanced settings. The driver on the laptop I just checked is: DeviceName: Realtek RTL8821CE 802.11ac PCIe Adapter DriverVersion: 2023.79.619.2018

We have a fair amount of these laptops, provided to staff and I've probably only come across one issue with regards to Wi-Fi, but it's not Teams related. One member of staff has issues connecting via our VPN when at home, on both his EE home broadband connection and his partner's EE home broadband connection, where the connection will just drop out or fail to connect. When in school on our backup Wi-Fi, it seems to be fine. So I just put it down to an issue with EE.

We have the Huawei and TP-Link ones. For the Huawei dongles, we only see the splash screen if we connect the directly connect the dongle to the machine via USB. If we turn on the dongle and search for the hotspot on a device, we can join it using the SSID and password printed inside, above the battery and it doesn't take us to the splash screen.

Ahh, it does and I've set SkipOOBE=true, because I wanted to avoid stuff like keyboard setup, etc.

I'm not sure where I'm going wrong. I've used Windows System Image Manager to create an unattend.xml file and it's working in terms of it's automated the install, to the point where it asks to join the WiFi. I then generated the hash, imported it into Intune, then waited 15 minutes. I joined the WiFi and it just proceeded with the automation process and created the local admin account, defined in the XML and takes me to the Windows log in screen. At no point does it look for policies online, or ask me to sign in with my Azure AD account. I'm not sure how to specify that in the unattend.xml.

I'm pretty sure I already know the answer to this, but I'll post anyway: We have a bunch of Ergo Hybrid 101 devices that are gathering dust, and we want to deploy them out to students as Intune devices. Our issue is that these devices all have the same serial number of: "Type1 - 123456789", with a separate sticker with a unique serial number on the chassis. The BIOS is extremely limited and doesn't even display the serial number, let alone have an ability to change it. I've gotten the serial number from however the BIOS exposes it to the OS, so via Powershell or similar. Is it possible to change this serial via a tool of some sort?

We don't fully remove the apps, but run "systemreset.exe /cleanpc" at the OOBE stage. This removes the full apps from the machine, such as McAfee, VPN. It still leaves stub installers, tiles in the Start Menu for McAfee, VPN, Netflix, etc. We're OK with this, as users aren't local admins, so have limited access to install things. Our process is: 1) At the OOBE screen, Shift+F10 to get the command prompt and use a script on a USB drive to get the hash. 2) Import the hash to Intune and wait 15 mint minutes for Intune to process it 3) During this 15 minutes, from the command prompt, run "systemreset.exe /cleanpc" 4) Windows will reset, with the apps removed 5) If this completes before the 15 minutes has passed, continue to wait (we've found this 15 minute window important, as if you proceed prematurely, before Intune has processed it...it messes up to Windows install) 6) Continue through the OOBE process and when joining the WiFi, it should automatically pick up your Intune policies

We have a bunch of old laptops that we are considering handing out to students in addition to the DfE allocation we've had. Since they're school devices and not been used in a long time, they're on older versions of Windows and they're tied to our SCCM configuration. I'd like to install the latest version of Windows (that they support) and then import them into Intune, so that they become Intune managed devices only, which is exactly how our DfE laptops are. To do this, I'd need to reinstall Windows, but I want to make it as seamless as possible on the install side, as we'll be doing quite a few devices. So automate as much as possible. Ideally, I want it close the OOBE experience that the HP 250 G7 laptops had, where Windows was already installed, just the OOBE setup needed completing. So basically: 1) Install Windows (automated) 2) OOBE setup, mostly automated apart from the join Wi-Fi stage 3) At this stage, use the command prompt to generate a hash to CSV 4) Import the CSV to Intune and wait 15 mins 5) Join the Wi-Fi and it should pull the Intune profile I've used SCCM for such a long time, I'm not sure what the best way to go about this is. Would MDT do this? Or would I need to use the Windows System Image Manager? Also, how is Windows licensing managed on Intune? Our site uses AD Activation/KMS (whatever it is these days) to handle activation of clients, however I don't know how cloud only devices work.

It sounds like you deployed the MSI version of Teams - this version cannot and will not automatically update. I believe you can download and deploy a the new MSI every month or however often you decide to do it and that should work. However, I had issues with this, as it wasn't actually installing the updated MSI. When a user runs the shortcut for the MSI version, it runs "C:\Program Files (x86)\Teams Installer\Teams.exe", which then installs a copy of that version of Teams into "%LocalAppData%\Microsoft\Teams". This causes a multitude of problems if you try and replace this MSI version with the normal EXE version. I ended up removing the MSI version from all workstations and pushing the EXE version. Though, it also wasn't a straightforward process and I wanted to have as little disruption as possible. Also, despite the MSI is installed as 'User', the user cannot fully uninstall it. They can remove it from Apps & Features and also run msiexec /x to remove it - but it won't remove the folder from Program Files (x86), because the user doesn't have permissions. So I created a GPO to delete that folder at system startup. I then created a batch file that runs gpupdate /force to get that GPO and remove the folder and then executes a Powershell script. The Powershell script checks if the MSI exists and removes it if it does. It then checks to see if the EXE version is installed in %LocalAppData% and also removes that. Then it installs the latest EXE version from our network share. This script was put on staff desktops and in the staff share, so they can run it at their convenience (otherwise forcing it may interfere with their lessons). It was a complete ball ache, but it seems to be working.

We've imported all of our AD users into Google Admin Centre and I used one of those accounts. When I was on the first setup stage of CloudReady, I joined the WiFi and tried to log in with one of those synced accounts, which is when it said I couldn't use an enterprise account.

Yeah. I've tried reimaging one with the Home Edition and it won't let you log in with an enterprise account. These devices aren't managed by our Google Admin, only the users are synced. Neverware support have just got back to me and only the license holder (with the my.neverware.com account) can install the OS and manage the devices.

Ah, OK. Just had some clarification. These are 'donated devices' that have been provided by BEP (Birmingham Education Partnership). I will contact them and see what they say.

I'm only going off the BGInfo type data on the background: Client ID: CloudReady-40:a8:f0:a5:51:48 OS Version: 85.4.1 License Type: 2021-06-09 Site ID: 24747 In the Settings, there is an 'About CloudReady' option, which says that CloudReady is copyright Neverware and Chromium.

That doesn't seem to work. Pressing Ctrl+Shift+Alt+R on the login screen does nothing. Turns out Neverware have disabled this in CloudReadyOS. They only recommend following their install guide.

We received a fair few ChromeOS devices last year, as part of the DfE scheme. They were all distributed to students, but some have been return as they're no longer needed. I want to factory reset them before handing them out to another student, but can't figure out how. I've contacted Neverware, to see if I can get an ISO, but they say that we need to pay for licenses to use anything more than the Home Edition (which doesn't let you log on with Google Education accounts). I'm not sure how the licensing works, because we didn't purchase them - these devices came with it. How can I factory reset these accounts, or remove the old student accounts from them before re-issuing them?

According to Microsoft, only Office 365 A3 includes Access (and Publisher). We only have "Microsoft 365 Apps for Students" and "Office 365 A1 for Students" licenses assigned to our students, and they can use Access. I believe that Microsoft 365 is the new name for Office 365 A3.

Literally a few minutes after posting this, I found a Microsoft Community post by Mzolo (bottom of page 2) post where someone suggested running Teams in Windows 7 compatibility mode. It worked! So if anyone comes across this: 1) Fully exit Teams 2) Change the Teams shortcut to run in Windows 7 compatibility mode 3) Load Teams 4) Sign in when prompted 5) Teams will load as normal 6) Remove compatibility mode from the shortcut (and Teams will continue to work) It seems that it has something to do with Teams losing authentication and wanting you to re-authenticate. Because Teams, it's borked and doesn't prompt you with the login screen and just stays on the Loading... screen. Compatibility mode appears to kick it back into life.

The app version of Teams on my desktop is stuck permanently stuck on "Loading Microsoft Teams..." splash screen and won't progress further, even if left for days. I can't figure out how to resolve it. I have been attempting to troubleshoot other Teams issues and it's meant I've installed, uninstalled and re-installed Teams many times on this machine. I suspect that this is the root cause of the issue, as the same thing has happened on another machine (a remote staff laptop) that I've repeatedly installed/uninstalled Teams on. Things I've tried: - Completely uninstall & reboot - Uninstall and clear "%LocalAppData\Microsoft\Teams" - Clear profile from machine entirely (DelProf2) and reboot - Cleared temp files via System Cleanup - Removed all stored credentials from Credentials Manager - Cleared Teams folders from %ProgramData% - Removed Office 2019 Professional Plus entirely from the machine and reinstalled None of the above worked. Anyone encountered this?

I couldn't resolve this and resorted to just changing all paths to FQDN, so mapped drives, home folders, shortcuts and other services.

We have 120GB SSDs in the majority of our desktops and we often find that the drives fill up. It's mostly either the SCCM cache or local profiles on the device, once multiple users have logged on. We'll be looking at 240GB+ on our next lot.

We're using Microsoft's SCEP, which I don't believe will restrict Teams from updating and have no SRPs in-place for staff. That's pretty much what we've done. Machine-Wide installer for staff, which installs to AppData and students using school computers, use the web version. Does that mean you're manually deploying a new MSI when you need to deploy updates?

We deployed Teams out to our staff using the MSI via SCCM (msiexec /i Teams_windows_x64.msi /q OPTIONS=”noAutoStart=true"). That's all well and good, however all of our users are now getting messages at the top of their Teams window saying "Looks like you're running an old version of Teams. Update the app to continue to using Teams on this device". Some research suggests that this message appears for client versions older than 3 months and the app is supposed to auto-update every two weeks. Microsoft say that Teams won't auto-update if it's installed to the Program Files folder, but only will from when installed to the AppData folder. Ours is installed to AppData (the default location), so that doesn't seem to be the reason. If I press the download link, it'll download the setup file and I can install it that way. This is affecting users both on-site and off-site. How are you managing the Teams client updates?

And the 3080!