Spangle

Did you end up staying with LUCID? surely there must be a cloud alternative out there? Dan

I found this out recently to, still not fixed in 1809. I've raised it with WSUS Guru Adam Marshall who was going to look into it. It would be a really handy feature if it worked.

I use a thin reference image with run-times and updates and everything else i add at build or by GPO after. I'm looking to bundle application installs together on PDQ. Using MDT to kick these off with a script. Therefor if Dept a have applications A, B and C. At some point application B is updated and rolled out to clients. Rather than having to update the task list in MDT with the new package, The script will be pointing to the same dept bundle on PDQ but now with an updated packages.

Thanks for the suggestion. Having gone through it all again today it would appear that the machine is up to date! The 0x8000ffff being displayed because there are no updates for the machine. Which would explain why the feature update works, then we get a few updates updates through before the 0x8000ffff error. Thanks a lot Microsoft.

I'm trying to plan a feature upgrade from 1709 to 1803 using WSUS. After the feature upgrade down loads and installs. the test clients download some additional updates and then fail with an error 0x8000ffff. Machines built from an 1803 MDT Build don't seem to have the issue. Anyone come across this before?

Is your server virtual? Try building a virtual workstation.

Sorry to bump this old thread but this has been a headache of mine for some time. Up until now i have tripped the APPS out of the custom wim before deployment. I have now had some success running the GPMC on a windows 10 VM. This does not crash when referencing apps installed. Having been banging my head on this one for ages i wanted to get it out there for others to see.

I built a couple of MDT servers which work great for me. When another admin logs in and tried to update the share i get the following: === Making sure the deployment share has the latest x86 tools === === Processing LiteTouchPE (x86) boot image === Building requested boot image profile. Determining if any changes have been made in the boot image configuration. Loading the existing boot image profile for platform x86. Calculating hashes for requested content. Changes have been made, boot image will be updated. Windows PE WIM E:\DeploymentShare\Boot\LiteTouchPE_x86.wim will be used. Unable to mount the WIM, so the update process cannot continue. === Completed processing platform x86 === === Making sure the deployment share has the latest x64 tools === === Processing LiteTouchPE (x64) boot image === Building requested boot image profile. Determining if any changes have been made in the boot image configuration. Loading the existing boot image profile for platform x64. Calculating hashes for requested content. Changes have been made, boot image will be updated. Windows PE WIM E:\DeploymentShare\Boot\LiteTouchPE_x64.wim will be used. Unable to mount the WIM, so the update process cannot continue. === Completed processing platform x64 === === Processing complete === I have added to users to local admins and got them to run the workbench app as an administrator but niether has worked. I'm guessing it's down to permissions but cannot find anything in the DISM log that highlights an error.

I found the issue in the end. It was a rouge GPO playing havoc with C drive access. It had been created a few years ago to allow some music software to run. Evrything seems to have settled down now.

If I try to install another Key KMS, MAK or even run slmgr.vbs -dli I get an 0xC0000022 error on these machines

Hi I deployed Windows 10 build 1703 over the summer using the Deployment Workbench to a mix of new machines and existing ones. I also set up one of my DC to activate Windows and Office by Active Directory. Out of 600 odd machines, I have a suite of new machines and a suite of rebuilt machines that are running into activation issues. Initially the machines activate correctly after 7 days activation fails also office failed to start. Other machines don't appear to have an issue. I reactivated my own laptop against the server no problem and the rest of the school aren't baying for blood. From the research I've been trawling through it points to the software protection service being some how restricted. Yet have try giving everything full rights to the service and still hit a brick wall. I have re built the machines which bought temporary relief until they tried to re licence. I'm really stumped why these two suites in different depts. with different sets of software on keep falling over.

Decided to remove the majority of apps from the build but leave the Store on there. That is then diabled by a GPO. This way we can enable it and reinstall any apps without a total rebuild should we have to. Not an ideal solution but a workable one for now.

I can remove apps successfully from the deployment image by mounting it with DISM and using the Remove-AppxProvisionedPackage command. Then i have an issue if someone wants an app reinstalling, there it no app to reinstall. I can deploy an image including all built in apps and dissable the apps with Applocker but then my start menu dies and becomes unusable.* Is there a powershell command (or other way) i could use to dissable the apps so should a user need them in the future they can be reactivated without a complete reinstall? *Once the applocker GPO is applied it only seems to work for the user who greated it localy and exported it. All other users have an unresponsive greyed out start menu. Build 1703 Education. Dan I thought 1703 was supposed to be enterprise ready!

Thanks for the heads up on the driver. Sanko are coming in tomorrow so I will get our Lab Technician to request this.

We've had Sanako 1200 in since last summer, It took untill feb for sanaco to get it working correctly, First they blamed the switch, then the network cards. Finaly they suplied a patch and driver. The only issue I've have since is that the headphones are susceptible to break (we now have abox full for Sanako to replace) and once assigned to a usb port they are not hot plugable.