jthompson

We've just got to wait a couple more days for their Asus EeePC netbook to boot up before they can post their thanks. They might even post a "meme", who knows.

You won't be able to stop them from sharing with other users in the school, though. In case you're being asked to prevent that.

The only thing that seems problematic there is the "share it" part. What does that mean in that particular instance? If it's sharing it publicly or with other external contacts, then that's a configuration on Drive that you can/should make to restrict your users to only being able to share within the organisation. You could prevent access to school accounts from non-managed devices, but I'm not sure you'd want to if you don't have 1:1 managed devices.

We don't. Certainly not for students. We also lock those profile fields so as to prevent end users from modifying them. Google usernames, display names and profile pictures are always publicly visible. You can't restrict their visibility to just your domain. IDK if the same is true for M365 profiles, but we lock those, too. EDIT: I stand corrected (maybe). I can now see that you can make your Google Workspace profile picture visible either publicly or only to the org. I'll have to see if there are any mechanisms to control that centrally.

The database is kinda separate in that it's running in an SQL Express instance, but you can install/provision it from within the MDT workbench UI, IIRC. To import details of all our computers from a CSV, I used some PowerShell scripting that's floating around on the web (stuff based on a PowerShell module names MDTDB.psm1).

So I'm guessing the db permissions article didn't solve it for you, then? It does seem like a credentials/permissions thing.

Good to know. I'll be asking our exams officer to arrange some system test keycodes ahead of our upcoming exams, then!

Long-pressing an Android quick toggle (e.g. Bluetooth, Hotspot, etc.) will take you to the relevant Settings page for that item. Android 13, at any rate.

How are you managing Windows Updates more generally? WSUS or WUfB? If it's WSUS I wonder if there's some Group Policy or WSUS product selection that's in the mix.

It's quite a small 'list' for us, so it's basically only documented in as much as most of it is GPO-based deployment (each piece of software being deployed has its own dedicated GPO, so the GPOs' scopes tell us what is being deployed where). Only a couple of bits of classroom software aren't being deployed automatically here (SOLIDWORKS and Cubase). Our workflow for reimaging a machine is trivially short, but carries a note to remind us that classroom machines in DT will need SOLIDWORKS and music machines will need Cubase.

I guess the equivalent value for you to use would be MDTDeploy$. Might be worth checking the db permissions. This seems like a reasonable guide to follow for that: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/deployment/deploy-windows-mdt/use-the-mdt-database-to-stage-windows-10-deployment-information#configure-database-permissions

I think the credentials are for accessing the deployment share as a whole, rather than for the database as such. I think you're missing the "SQLShare" parameter in your CSettings. This is the CSettings section from our deployment share rules: [CSettings] SQLServer=MDTServerName Instance=SQLEXPRESS Database=MDT Netlib=DBNMPNTW SQLShare=DeploymentShare$ Table=ComputerSettings Parameters=UUID, AssetTag, SerialNumber, MacAddress ParameterCondition=OR

It is in our environment. Turning TLS 1.0 back on on the client gets the software working. It seems surprising given how close to deprecation TLS 1.0 must be now in regular Windows 11 home computers.

We don't put the user creds in the bootstrap.ini file. WinPE will then prompt for credentials when it first attempts to access the share. That's how we do it, to prevent anyone other than us from initiating imaging.

The errors before the attempt to connect to the database are likely where your issue is. Those log entries say that it's trying to connect without a username. Are you expecting that? I'd have thought you'd be providing credentials for the client to access the deployment share.

Yes. LinkMaker is used by loads of local authorities and agencies around the country, so our experience of it was more like online dating: searching for childrens' profiles and filtering for age, ethnicity, needs, etc. Hard work and you can't read too many profiles of an evening. As a potential adopter you have to really sell yourself in your profile and make yourself stand out to the social workers around the country who will be trawling through adopters' profiles. When you want to register an interest in certain children, you may not hear anything back if that child's social worker is pursuing other adopters, or just doesn't feel like you're a good enough match. The scene where the children are reaching out of the pages of the brochure choked me up, because that's how it felt. You're told to hold in mind that most of those children will find a family that is suited to their needs - it just happens that it's not going to be you.

Anything in the client logs? The only thing I can think of to suggest is checking whether you've got TLS 1.0 disabled on the server. If you have, try turning it back on for a test.

We've been watching Lost Boys and Fairies on iPlayer (we've not watched the final episode yet). The portrayal of the adoption process, in particular the adopters' emotional reactions to it, are absolutely... spot... on. Usually when watching a TV programme or film about something you understand better than most it can be a frustrating experience (e.g. CCTV 'enhancement'), but it was clear from about 20 seconds in that the writers had written it because they'd been through the adoption process and needed to communicate it faithfully. We adopted recently and so many of the scenes are really hitting us. Plenty of tears.

ExamWritePad here mainly, with dedicated exam accounts with user areas. Exams are saved to the user areas, with EWP configured to save the regular automatic backups locally. Exam officers have privileges over the user areas. When stuff needs to be printed, that's printed at the end of the exam so that candidates can sign the hard copy before leaving the room. I wouldn't want to have USB sticks in the mix. That seems really messy to me.

I've tried using Power Automate for something similar, but I find that if an approver doesn't actually action anything or misses the email, then the Power Automate flow will eventually time out and create a bit of a mess of things with some requests efectively left in limbo.

We use GLPI for asset tracking (although it can do all the other stuff too), FreshDesk for our helpdesk and DokuWiki for our documentation wiki. Our DokuWiki site is hosted externally, so that it's available throughout any on-prem meltdowns.

Assuming that by debloat you mean removing unwanted AppX packages. I'm using MDT still, but I mount the vanilla image in PowerShell using Mount-WindowsImage. Mount-WindowsImage -ImagePath "E:\DeploymentShare\Operating Systems\Windows 11 Education 23H2\sources\install.wim" -Index 1 -Path "E:\Mounted" Then create an array of names of AppX packages I want to remove. $Apps = @( "*DevHome*" "*FeedbackHub*" "*GamingApp*" "*GetHelp*" "*Getstarted*" "*Microsoft3DViewer*" "*MicrosoftOfficeHub*" "*MixedReality*" "*News*" "*OneNote*" "*Outlook*" "*People*" "*PowerAutomateDesktop*" "*Skype*" "*Solitaire*" "*Todos*" "*Weather*" "*WindowsMaps*" "*Xbox*" "*YourPhone*" ) Run Remove-AppxProvisionedPackage agains each of those. ForEach($App in $Apps){ Get-AppxProvisionedPackage -Path "E:\Mounted" | where {$_.PackageName -like $App} | Remove-AppxProvisionedPackage } Then dismount and save the image. Dismount-WindowsImage -Path "E:\Mounted" -Save So that leaves the 'vanilla' image but with a bunch of unwanted AppX taken out. I initially tried removing the packages in a task sequence, but it wasn't a reliable method due to the inconsistent seqencing of those commands in relation to a user session being started in the background.

RE: MDT database connections, I know that when using Windows 10 2004 ADK or earlier, TLS 1.0 needs to be enabled on the server for the client to be able to connect to the database. I've never used FOG, but that's the only other thing that I know of that might be worth considering apart from plain WDS. SCCM (or MECM or whatever it's called this week) is probably a faff to set up but perhaps worthwhile in the long run. We switched to MDT from WDS when our WDS stopped being able to auto join new computers for some reason that we never got to the bottom of.

Is the server's network connection identified as a domain connection? If it's sitting there identifying as a 'Public' connection, that would explain it.

When you say that students aren't able to run batch files, do I take it that that prevents you from having a login script run those vboxmanage commands? That's going to be risky for you, since you'll need those in order to prevents students from modifying the VM to give it network access, or switch the disk to something else that they've brought in, etc. The logon script also registers the VM with VirtualBox, so that the vm can then be started from a shortcut. The shortcut will be running VirtualBox with parameters to start that VM, but the VM needs to have been registered for that to work. That all needs to be done in the user's context (which is why it's a logon script). We use AppLocker to allowlist batch scripts for our end users, so that logon scripts can be run successfully but the end users can't just run random bat files.