Mako

Forbidden caramel.

E-mails going awry (particularly to students instead of staff etc) has been heavily mitigated by implementing custom address books and custom GALs. No student names auto-fill now, staff will only be auto-filled by other staff. If they want to e-mail a student then they need to go out of their way to do it by using the address book. It has also stopped staff accidentally e-mailing other staff across the Trust, as they can only see colleagues within their own school. Again, if they want to contact a colleague at another school they need to use the appropriate address book. Staff are free to use the Contacts feature of Outlook to set up their own contacts or frequently-used users. Equally, students cannot see any students outside of their own school and don't get auto-filled by other students or staff in the Trust. It was a bind to set up but the amount of human error has dropped significantly to the point where I can't remember the last time it happened, I set it all up over a year ago due to new schools joining the Trust.

If you convert 3137322e31362e312e31343700 to Text with ASCII, it comes back with 172.16.1.147 which is the IP address it was assigned. The device is sending back its assigned IP address as hex in the packet. I'm not an expert in this field but I did some Googling (starting a search '3137322 + DHCP' got some interesting results) and went down the road of it being something to do with BOOTP and/or the device is sending back corrupt packets. This sounds about right as in the OP, the 'type' is 'DHCP/BOOTP', rather than just DHCP. It could also be a rogue device. If you can acquire the MAC address from your switch(es) ARP table you might be able to narrow down where it is. I also went on a route of this being something to do with access points, so that's also a possibility.

You can set up users on iVMS and on the Hikvision server then limit access. Eventually we are going to have a dedicated CCTV viewing room with a desktop with iVMS on. We created user accounts with restricted actions, they can only access cameras based on user and can't access any of the system settings etc, basically turning it into a Viewer and Exporter. Edit: if they log in again, it should offer to save the credentials (if they know them).

I have personally found the Hikvision web UI to be horrendous - plugins required, and you can't play back more than 1x speed. You can't easily save or export clips. After installing iVMS-4200, life is easier, but it does have some beefy system requirements. It killed my older desktop. To answer your question they probably got Chrome to save the credentials as it probably detected it was a username/password combination.

This. Operate on the principle of least privilege. Here all IT staff have at least two accounts; a 'day-to-day' account and an 'AD account' to perform tech functions. Day-to-day accounts are standard users, no different from teachers or other users. The only difference is we have less restrictive GPOs which allow us to see more bits of Windows. This does not grant more privileges, but allows us to get to things where we can elevate our privileges or just see more information. We cannot run command-prompt, for example, but we can elevate it as another account, such as the local administrator, to do things. The AD accounts are added to one or more groups in AD, and those groups are delegated privileges according to function; such as Tech Group Modification, Tech User Modification, Tech Reset Passwords, Tech Computer Modification etc. These groups have functions delegated via Delegated Access in AD to one or more OUs based on that need. The AD accounts are only able to be used on nominated workstations that have RSAT tools installed where technicians must elevate their permissions with these accounts. The AD accounts are denied logon rights to all devices except those named in the Authorised Workstations group. We do have separate local admin accounts per-technician but after implementing LAPS, these are being phased out. In any case, any local admin accounts are added to gen-pop workstations only via Restricted Groups in GPO. More privileged IT staff also have a 'server user' and a 'server admin' account. The 'server user' account is also a standard account but it is added to the remote desktop users of servers to allow remote logon. They must then elevate permissions via the 'server admin' account, which is only added to the server's built-in Administrators group - not domain or enterprise admins. Anything requiring Domain Admin privileges goes through a special process. Nobody uses the default domain Administrator account. No accounts used for general administrative functions are added to Domain Admins. Both these accounts are denied logon rights to all devices, except servers, via GPO.

As more data is going to SharePoint, Teams and OneDrive, since 2022 I've been connecting laptops directly to Azure (Entra). Due to some legacy drives and such they need a bit of manual attention during the initial setup, but after that they're good to go. I can't say that we're 'fully' inTune but for the most part the staff that have been issued a laptop have not had a single issue (outside of actual technical problems with the device e.g touchpad) and there's configuration profiles set up etc. Since September, all new staff and students have Known Folder Move for OneDrive and I've deprecated home drives entirely. For any new staff with a device it means that they have a seamless experience. Existing staff are free to move their home drive data to OneDrive at their convenience then they can be moved onto the Known Folder Move on-prem.

As above, you have no right to force anything onto a personal device. Everything must be at the user's discretion and you should provide the option of doing it. For example, we use a Smoothwall. After connecting to the BYOD network, it redirects the user to the certificate page to download and install the Smoothwall certificate. They can choose not to, in which case their ability to do anything is almost entirely inhibited. Because of this, most students choose to use their phone's data rather than school WiFi but that's not our problem as they're not using our services. Anything owned by the school should be managed and therefore it should be enforced.

Going off your screenshot, is this happening in Excel only? Or does Excel just happen to be in the background? It looks like a document, plugin or external data source is linking to stackssl.com which seems to be redundant now. As evidenced by the pop-up, the certificate has long since expired.

Also currently running Descent Into Avernus after gamer friends enjoyed Baldur's Gate 3. I haven't played D&D since college but I came out of DM retirement to run this and they only have experience of a few one-shots they've done between themselves. If they enjoy it, I do have a campaign ready to go from days of yore, although I'd need to refactor it for 5e.

Microsoft advised the deprecation of Stream Classic a while ago. https://learn.microsoft.com/en-us/stream/streamnew/stream-classic-to-new-migration-overview#migration--retirement-timeline there is a guide on how to migrate here https://learn.microsoft.com/en-us/stream/streamnew/stream-classic-to-new-migration-overview However if you're not prepared, you need to hop into your Stream Admin centre and re-enable Classic (handy page: https://web.microsoftstream.com/admin/?view=MigrationSettings) You will need to check "Scheduled", and the absolute cut-off point is 15/04/24, that is the date by which Microsoft will disable it for good.

Is Password Writeback enabled as part of your Entra Connect sync options? If so, disable it. You can also head to https://entra.microsoft.com/ -> Protection -> Password reset -> Properties -> Set "None" for Self service password reset to disable users from resetting their own passwords online.

If your old server is now in staging mode then it won't be sending data to 365. If you've just made this change then it might take a while for 365 admin to show the new data source.

Not to derail the topic but if your estate is large enough, it is a good practice to have a secondary instance set up in staging mode. We have this here in case our primary site goes down. If you are a single school and/or only have a few servers, probably not necessary. This is also just a good read in general. https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-topologies

I have it so 1 PSU goes into 1 UPS and the other PSU goes into another UPS. Plugging directly into mains can introduce power spikes directly to the PSU if there's an issue with the mains, which could cause a PSU failure, whereas your UPSes should protect against that.

Have you recently changed to/from these IP ranges? Try and do things (ping Google, browse the web etc) and look at the live Firewall logs - ensure you have logging enabled on all the rules. You should be able to catch what's going on. I've had it on a remote site where we changed IP range and the Smoothwall was sometimes seeing the devices as external and blocking them on the default external rule, i.e dropping the request.

Has this just started happening or has something recently changed (such as moving the VMs from VLAN 1 to 2) ? If they can ping in one direction but not the other, it sounds like a Smoothwall rule that's mono-directional. But if you've not changed anything then that's a headscratcher.

I don't think so. Someone may correct me if I'm wrong. It is possible to export the config from AD Sync but I'm guessing that hasn't been done.

That is entirely up to you and what you want to achieve - if you select all OUs, then everything in your AD will sync. Having computers sync can be useful if you want to (co)manage via Intune. If you want to have it where users are removed from 365, then unselect that particular OU. For example, we have an Archived Users OU. If someone gets moved there, they're no longer sync'd and will be removed from 365.

ACL on the gateway switch? Funky Smoothwall firewall rule preventing access from network to VM? You're having trouble pinging to the VM, but can the VM ping out to known devices?

The Preparing Windows state is where the OneDrive and Teams (if installed) clients get installed on the user's account. By default, the clients are installed in per-user setting and will actively download/update the client for each new user. Converting them to Machine (instead of user) installs can speed up the process as they can install/be used from the local hard drive rather than download for each user that logs in. Edit: It's not a life-changing amount of time gained, but it is noticeable. Further, I am now actively making new staff and students default to OneDrive Known Folders so we don't use folder redirection anymore. Users that are fully OneDrive have quite a rapid login.

We recently had a few borked installs of Cubase. A full reinstall did nothing. Re-imaging the PC did nothing. Using the same installer on other computers worked fine so it was a real headscratcher. Downloaded an updated installer from the Steinberg website which seemed to fix the issue. On the problematic PCs, the installer actually said "Will be updated" for the Groove Agent and HaLion Sounds, and it seemed to fix the issue. It hasn't reoccurred since.

You'll need to open the AD Connect (Soon to be Entra Connect) Sync on your on-prem server, and change the sync options to include your new OUs.

I've just gone through the same process as you: "Create a new group" via Policy Wizard > Called it "Test" > Head back to Directories Page> Expand AD > Add New Group Mapping

Look at Privileged Identity Management in Azure if you want to avoid fixed accounts with statically assigned roles. Senior IT staff have separate admin accounts but technicians have been assigned just-in-time roles in PIM which, depending on the role they want to elevate, may require admin approval. They have to fill in a box which details the reason (or in our case, the ticket #) for elevating for auditing purposes. All elevations require MFA approval. It does mean that if a tech's day-to-day account was compromised, the attacker would severely struggle to access those permissions as they'd also need the tech's MFA which is no different then a separate account being compromised. The roles can be customised to detail how long the privileged access is granted, and whether or not that role needs admin approval etc.