Search the Community

Hi I have an issue whereby my Windows 10 IPU task sequence is downloading all driver packages specified in the TS (Download Package Content) allthough the correct driver packages already exist in the CCM cache on the PC running the TS. I have used the following guide to create a PreCache task sequence: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-1/ (credit to Martin Bengtsson for the excellent guide) and it works very well. A PC which has successfully run the PreCache TS downloads the correct drivers (using a WMI query) and other packages specified that are needed and then places the computer in a collection to where the actual IPU task sequence is deployed. The problem is that the IPU task sequence which is deployed with the setting "Download all content locally before starting the task sequence" (the setting found under the "Distribution Point" tab) starts to download driver packages for other hardware models that are specified in the TS (despite using WMI queries in this TS also). Because of the current Covid-19 pandemic the majority of our users are working from home so we obviously want to keep the amount of data transfered to a minimum, it seems stupid to cache driver content that´s not needed to work around the problem. I thought that the IPU TS would evaluate the queries before downloading (i read somewhere that this was only possible for upgrade packages/language packs but in later versions of current branch also included other packages). We are running CB 1910. Hope this makes sense, if anyone has experienced this and can suggest a workaround or confirm how it´s supposed to work it would be greatly appreciated. Regards Emile

Hello, hoping for some help from with a strange issue I have on a customer site I am currently unable to build Dell Optiplex 5040 devices with Windows 10 1909 x64 Enterprise from an Endpoint manager 1910 MDT integrated task sequence. The task sequence fails when trying to execute the Invoke-MbamClientDeployment.ps1 script. I have detailed the high level tasks below and attached the SMSTS.log. BIOS upgraded to latest version BIOS Reset to factory settings BIOS Password Set BIOS Standard config applied UEFI Boot enabled TPM Cleared & activated TPM Converted from 1.2 to 2.0 TPM Cleared again and reactivated OS Deployed Drivers deployed MBAM TPMPassTheHash step completed DOTNET Enabled C++ Redists applied Security Patches Applied The MBAM Group MBAM_XTS_AES256 applied to reg PreBoot Input Protectors for Tablets applied to reg MDOP MBAM 2.5 SP1 Installed MBAM Client Hot Fix KB4505175 Applied Sleep 2 mins DisableRootAutoUpdate (Certificate applied) Restart Set PowerShell Execution Policy Set to bypass Set PowerShell Execution Policy powershell.exe -command Initialize-TPM Is run **THE STEP THAT FAILS** Invoke-MbamClientDeployment.ps1 with the below parameters Parameters - -RecoveryServiceEndpoint "https://MBAM:443/MBAMRecoveryAndHardwareService/CoreService.svc" -StatusReportingServiceEndpoint "https://MBAM:443/MBAMComplianceStatusService/StatusReportingService.svc" –IgnoreEscrowOwnerAuthFailure -EncryptionMethod "XTSAES256" **The Post Steps** Reset TPM Policy EnableRootAutoUpdate The TPM status is Enabled, Activate & NOT owned The above works on all other models tested but fails on the 5040 The actual error message received is contained in the smsts.log file attached and the extract is below. The device is also in a staging OU that receives no Group Policy. The device does register in MBAM if continue on error is checked on the offending task and the computer object moved to the correct OU but will not encrypt. The same task sequence works on the other Dell models tested e.g. 5050 I have logged in after and BitLocker throws a internal error if you try to run it manually. **THE ENVIRONMENT**** A single site deployment of Endpoint Manager 1910 with two distribution points deploying Windows 10 1909 x64 enterprise with a MDT Integrated task sequence. The Dell command tool kit has been integrated into End Point Manager and drives the BIOS/TPM config steps in the task sequence. The Dell TPM conversion tool is used to convert the TPM to 2.0. The devices been build are production Windows 7 and are been repurposed as Windows 10 x64 Enterprise 1909

I am new to Task Sequence. I am working on a task Sequence to convert BIOS (Legacy) mode systems to UEFI mode systems (Dell Laptops)(SCCM with MDT) . Can some share a task sequence to do so or share your experience to do so. Actually my requirement is to add these steps for PXE OSD win 10 1607 task sequence.

Introduction Microsoft released the new Surface Pro and recently a new operating system, Windows 10 version 1709 (Fall Creators Update). Now you can automate the installation of it using PowerShell. This script has been written to allow you to automate the deployment Windows 10 version 1709 (Fall Creators Update) using the latest available software including: Windows 10 x64 (version 1709) Microsoft Deployment Toolkit (MDT) build 8443 Latest available 2017 drivers for the Surface Pro Windows 10 ADK (version 1709) Windows Server 2016 Note: This is fully automated, and as this does install a Windows Deployment Services server role hosting a boot image, you should modify the script accordingly and test it thoroughly in a lab first. This script is tailored for one thing only, deploying Windows 10 x64 version 1709 to the Microsoft Surface Pro with all drivers loaded and MDT 2013 preconfigured. Download it and customize it to suit your needs for other hardware if you wish because what it does is pretty cool. This script performs the following actions:- Downloads and then Installs Windows ADK 10 (version 1709) if you have not done so already Downloads and then Installs MDT, if you have not done so already Downloads all required drivers for Microsoft Surface Pro if you have not done so already Imports the Windows 10 x64 (version 1709) operating system into MDT Imports the Microsoft Surface Pro drivers into MDT Creates Selection Profiles for Surface Pro and WinPE x64 Creates a Deploy Windows 10 X64 version 1709 task sequence Edits the Deploy Windows 10 X64 version 1709 task sequence and adds an inject drivers step for Microsoft Surface Pro Sets a WMI query for hardware detection for the Surface Pro on the corresponding driver step Injects the Microsoft Surface Pro network drivers into the LiteTouchPE_x64.wim Creates custom CustomSettings.ini and BootStrap.ini files Disables the X86 boot wim (as it is not needed for Surface Pro) Changes the Selection Profile for the X64 boot wim to use the WinPE x64 selection profile Installs the Windows Deployment Service role Configures the WDS role and adds the previously created LiteTouchPE_x64.wim Starts the WDS service so that you can PXE boot (UEFI network boot). All you have to do is download the script below, modify some variables, then place certain files in the right place such as the Windows 10 x64 Enterprise (version 1709) media. Please ensure you have a working DHCP scope on your Active Directory domain controller, then PXE boot a Microsoft Surface Pro and sit back and enjoy the show. Step 1. Download the script The PowerShell script will do all the hard work for you, it is in the Downloads section at the end of this guide, download it, unzip it and place it on the server that is designated to be the MDT server. Step 2. Configure the variables in the script Once you have downloaded and extracted the script, you need to configure certain variables interspersed throughout the script. I'll highlight the ones you need to edit. The most important of them is the $SourcePath variable (line 53) as this decides where to get the content from and where to store it. This variable should point to a valid drive letter, the folder name will be created if it does not exist. The $FolderPath variable (line 237) specifies the MDT Deployment share root folder for example C:\MDTDeploy. There are other variables to configure, for joining the Domain (lines 315-317) and then you need to configure how you actually connect to the MDT server from WinPE (lines 392-396) Step 3. Copy the Windows 10 x64 (version 1709) operating system files Mount a Microsoft Windows 10 x64 Enterprise (version 1709) ISO and copy the contents to $SourcePath\Operating Systems\Windows 10 x64\1709 as shown below Step 4. Optionally copy MDT, ADK 10, Surface Pro drivers This is an optional step. If you've already downloaded the above files then place them in the source folder, otherwise the script will automatically download them for you. Note: You do not have to do this as the script will download the content for you if it's not found. Step 5. Optionally copy your Applications to the respective folders This is an optional step. If you have apps like Office 365, copy them to their respective folders under Applications. If you do add any applications, you'll need to edit the corresponding section within the script for the CustomSettings.ini and replace the GUID for the App, these applications are remmed out with a #, as shown here (line 358) and here in line 294... Step 6. Run the script On the server that will become your MDT server, start PowerShell ISE as Administrator. Click on the green triangle to run the script. Below you can see the script has completed. After the script is complete, you are ready to test deploying Windows 10 version 1709 (Fall Creators Update) to a Microsoft Surface Pro. You can see that Windows Deployment Services is installed and that the ADK 1709 version of the MDT LiteTouch_X64 boot wim is already imported. This boot image also has the Surface Pro network drivers added. After opening the Deployment Workbench, you can see the Deploy Windows 10 x64 version 1709 task sequence is created The Surface Pro Inject drivers step is pre-configured for you and the WMI query for the hardware is also added on the options tab drivers specific to the Surface Pro for are imported into MDT Step 7. Sit back and watch the deployment Take a properly shutdown Surface Pro , and power it on using the following sequence. Hold the down volume key and then press the power button while continuing to hold down the volume key, it should PXE boot. Press enter when prompted before loading the boot image before prompting you for a computer name, note that it's currently set to SurfacePro in CustomSettings.ini contained within the script, you can change that behavior in the UI itself (CustomSettings.ini on the Properties/Rules of the DeploymentShare) or automate it via the many methods available such as those that Mikael describes here click Next and off it goes, with your customized Company name and after a while it's all done Troubleshooting If the script has issues starting WDS (and you see the error below) then restart the server, as you were asked to do at the end of the script ;-). If you cannot PXE boot, because WDS is not accepting connections (revealed by the PXE Response tab in WDS properties), then look for the following error in the scripts output: An error occurred while trying to execute the command. Error Code: 0x5 Error Description: Access is denied. If you see that error, then the user you are logged in as does not have sufficient permissions to configure WDS. To grant permissions to the Windows Deployment Server (MDT01) do as follows Open Active Directory Users and Computers. Right-click the OU where you are creating prestaged computer accounts, and then select Delegate Control. On the first screen of the wizard, click Next. Change the object type to include computers. Add the computer object of the Windows Deployment Services server, and then click Next. Select Create a Custom task to delegate. Select Only the following objects in the folder. Then select the Computer Objects check box, select Create selected objects in this folder, and click Next. In the Permissions box, select the Write all Properties check box, and click Finish. Repeat the above process to grant appropriate permissions for the User who will run the PowerShell script Summary Automating the deployment of Windows 10 version 1709 (Fall Creators Update) to the Microsoft Surface Pro using PowerShell and MDT is easy when you know how. Downloads Download the PowerShell script contained in the ZIP file. Deploy Windows 10 Fall Creators Update to Microsoft Surface Pro with MDT - November 2017.zip

Hi, I'm upgrading our Windows 10 clients to 1703 build and i'm using a built-in task sequence in order to upgrade it. I tried servicing plans and it works well but i want to upgrade a Displaylink (display) driver after OS upgrade because the new build needs a new driver... so i decided to use a task sequence. I followed some posts from Niall (thank you!) and now i can advise to user, capture logs, upgrade multiple language (spanish & english), etc... https://www.niallbrady.com/2016/05/21/how-can-i-deal-with-languages-in-the-upgrade-task-sequence-using-system-center-configuration-manager-current-branch/ but i have a doubt, when the OS upgrade process step starts it reboots the computer automatically, can the user control this reboot? For example, when you deploy the feature upgrade using a service plan a soft restart is requested to user, so when he reboots the computer the upgrade continues. I want to improve more the user experience and give their this reboot control using a task sequence can it be possible? thanks and regards

I am upgrading 3000 PCs from Windows 7 to Windows 10 with SCCM 2012. There are 10+ different models (mostly HP). I've done about 400 so far. After the upgrade to windows 10, the Intel video driver is stripped and replaced by a generic Microsoft video driver. The different models require different drivers. How can I update the video drivers on the multiple versions of PCs during the OS upgrade task sequence? Thanks!

I'M wondering if anyone has had success in using the Upgrade task sequence in in SCCM CB 1710 to upgrade From Windows 10 1607 to Windows 10 1709 I haven't been able to do Successful Upgrade test when it rolls back.. On side note i haven't been able to successfully update my home computers without doing a wipe and load from 1703 to 1709 using the Creators tool Anyone know of any issues . With 1709 upgrade

Hello Folks, I'm new to this forum. I believe that this is right place to post my query here. Here is problem with SCCM. I wrote a script that copy file from desktop to shared location. the script works perfectly fine when I run as administrator. Created package \ application for this script and deployed to my test machine. but It doesn't do anything while installing from my test machine even though I checked run with admin's right in SCCM. FYI: Method 2: Created bat file that calls my power shell script. No luck yet all! Method 3: Run the Powershell script by using coomand line i.e Powershell -ExecutionPolicy -Bypass -file "file.ps1" in SCCM Package\ Application. But No luck yet all. Please share your thoughts.

I'M wondering if anyone has had success in using the Upgrade task sequence in in SCCM CB 1710 to upgrade From Windows 10 1607 to Windows 10 1709 I haven't been able to do Successfully test this it rolls back.. On side not i haven't been able to successfully update my home computers without doing a wipe and load from 1703 to 1709 . Anyone know of any issues . With 1709 upgrades

Introduction Here’s some links with videos of all the Microsoft Intune and Configuration Manager, Windows 10 & Office 365 ProPlus content @ Microsoft Ignite in Florida last month. Intune/ConfigMgr: Mobile device and app management overview with Microsoft Intune System Center Configuration Manager overview and roadmap Conduct a successful pilot deployment of Microsoft Intune Manage and secure Android, iOS, and MacOS devices and apps with Microsoft Intune Learn how to use Microsoft Intune with the new admin console and Microsoft Graph API Secure access to Office 365, SaaS and on-premises apps with EMS Manage and protect Office 365 mobile apps with Microsoft Intune Deploying and using Outlook mobile in the Enterprise Manage mobile productivity with EMS Windows 10 & Office 365 ProPlus: Microsoft 365: Modern management and deployment (general session with Brad and Rob) Overview: Modern Windows 10 and Office 365 ProPlus management with EMS Transition to cloud-based management of Windows 10 and Office 365 ProPlus with EMS Modernize deployment & servicing of Windows 10 & Office 365 ProPlus with EMS Secure Windows 10 with Intune, Azure AD and System Center Configuration Manager

We have a scenario in our organisation where we want to map a huge lot of environment variables for specific machines. Each and every variables are unique to each machine. There are around 6000 variables which needs to be mapped to 6000 machines. Is there any way we can handle it through SCCM ?

Microsoft has changed Windows As A Service and this was explained in a blog post by Michael Niehaus. As we announced back in April, Microsoft is aligning our servicing models with twice-per-year feature update releases targeting March and September, and 18-month servicing timelines for each release. While the first fully-aligned release will occur later this year with the Windows 10 Fall Creators Update release and a corresponding Office 365 ProPlus release, we got a head start with the Windows 10 1703 release (a.k.a. Creators Update): It marks the first of our semi-annual releases, each of which will be serviced for 18 months. As part of the alignment with Windows 10 and Office 365 ProPlus, we are also adopting common terminology to make it as easy as possible to understand the servicing process. The two most important terms to understand: Semi-Annual Channel. These are the twice-per-year feature update releases, targeting March and September, designed for the broad population of general-purpose PCs used throughout organizations. Each of these releases will be serviced for 18 months from the date of release. (The Semi-Annual Channel replaces the Current Branch [CB] and Current Branch for Business [CBB] concepts.) Long-Term Servicing Channel. These are less frequent releases, expected every 2-3 years (with the next one expected in 2019), designed for special-purpose PCs such as those used in point-of-sale systems or controlling factory or medical equipment. Each of these releases will be serviced for 10 years from the date of release. (The Long-Term Servicing Channel replaces the Long-Term Servicing Branch [LTSB].) With each Semi-Annual Channel release, we begin deploying right away to targeted consumer devices and gradually ramp up to full deployment based on the telemetry that we receive. As John Cable discussed on the Windows Experience blog, we recommend that enterprises follow the same approach. Start with targeted deployments to validate that apps, devices and infrastructure used by the organization works well with the new release. When that validation is complete, begin broadly deploying. Windows 10 1703 is ready for that broad deployment, based on feedback that we’ve received from organizations, ISVs, partners, OEMs, and consumers that have already done it. As a convenience to help organizations that haven’t yet begun this broad deployment, we are updating the Windows 10 1703 packages and ISOs on the Volume License Servicing Center, MSDN, Windows Update, Windows Update for Business, and Windows Server Update Services, integrating the July cumulative update into the original Windows 10 1703 packages. For more information on the common terminology, see the as well as the corresponding Office 365 ProPlus servicing guidance. Today we have also made available a new Microsoft Mechanics video to help explain the servicing process: And here's the video explaining the changes:

Cortana is a personal voice digital assistant created for Windows 10. With the release of 1503 version, it was working good to some extent. But compared to Siri and Google Voice it still had to go a long way. Also, it's irritating every time it opens a Bing search window, for things it doesn't know. I would love to see something like dictating text in Word, instead of doing web search using Cortana. Now comes the main point. Microsoft made sure that it can collect all the personal information, whenever you are using Cortana. In the 1503 version, it was very easy to turn it off. Also you can clear all the personalized data that stored on its servers. But with the Creators update, 1703 version, that easy option was removed. Microsoft made sure that it's consumers struggled hard and give all their information to it. So that it can make more money from its end users. But just like every hack and tweak the Microsoft community releases to circumvent the problems, Redmond creates. There is also some round-about option through which you can disable Cortana after Creators and Anniversary update. This is for people who want to type in their searches using keyboard and avoid the mic for doing searches. Also this will give you more privacy. The following 6 methods have been researched over the Internet to disable Cortana in Windows 10 1703 and 1611 version. Warning: But make sure you surely want to turn it off. Otherwise, it's difficult to enable back it again, though its possible.

I just upgraded to 1703 using a Servicing Plan in SCCM, however I lost all the pinned program from the Start menu. Also, I had to re-install the RSAT update. Wondering if you anyone had the same issue? Thanks,

hello, im after some assistance if possible. Im attempting to deploy a windows 10 image, i have created a reference image from within MDT then imported the WIM in SCCM 2012 r2 sp1 Cu2. I have built a new mdt task sequence within SCCM 2012 and have downloaded the windows 10 drivers for the surface pro 4. The image deploys to a virtual machine fine and joins it to the network, but im having trouble with the Surface pro. Sometimes it finishes installing drivers and then hangs on "getting ready"... other times it completes the osd but it hasn't joined the network. There is a step in the task sequence to apply the surface pro 4 drivers and it seems to run through that ok, there is also another step to automatically apply drivers which i have switched on at present... like i said the osd completes on a vm but not my surface pro 4.... cant figure out the exact step that fails the whole OSD ive attached the SMSts.log from the surface.... i can see it doesnt find all the drivers but was hoping it would be enough to enable the OSD to complete. any help would be appreciated. smsts.log

Hello, We are currently running Windows Defender client version is 4.10.14393.0, however in Programs and Features it showes System Centre Endoint Protection 4.7.214.0. Please note that we are pushing the SCEP policies via sccm Here is the screen captures : Any ideas?

Hello, i'm sorry if this has already been answered but i'm struggling to deploy Windows 10 (1607) to some Windows 10 (1511) machines from SCCM using Windows 10 servicing. Current setup: SCCM version - 1606 Windows 10 - 1511 (English) Enterprise Edition Within Windows 10 updates (under servicing) the feature update is listed in the console. I have created a service plan and when i run a preview the feature upgrade is listed (see screen). I have tried the feature upgrade with two different English languages "english-gb" and "english-us" but neither seems to work. The deployment ring is set to currant branch and the two systems i am attempting to deploy to have "do not defer upgrades" in operating system readiness. The language on my system is - 1033 the update has been downloaded and is on the distribution points, when i run the servicing plan and then wake up the systems they dont download the update. If i look into the motoring section under deployment the deployment is listed but the machines are set to complaint ?? any ideas?

Hello, We are running SCCM CB (1511) and I'm trying to push an package more than 70 workstations ,it's a mix of Win7 and Win10 . The package installs fine on the Win7 machines but not on the WIn10 workstation, the Deployment Status shows that it's "Waiting for a Service Window" I checked the execmgr.log and it shows : Succesfully raised SoftDistWaitingForServiceWindowEvent event for program AirMedia execmgr 8/8/2016 6:14:25 PM 6196 (0x1834) Execution Request for advert SE1200A5 package SE100121 program AirMedia state change from Ready to WaitingServiceWindow execmgr 8/8/2016 6:14:25 PM 6196 (0x1834) Raising client SDK event for class CCM_Program, instance CCM_Program.PackageID="SE100121",ProgramID="AirMedia", actionType 1l, value , user NULL, session 4294967295l, level 0l, verbosity 30l execmgr 8/8/2016 6:14:25 PM 6196 (0x1834) CServiceWindowEventHandler::Execute - Received SERVICEWINDOWEVENT : START Event execmgr 8/9/2016 9:27:02 AM 4080 (0x0FF0) CServiceWindowEventHandler::Execute - Received SERVICEWINDOWEVENT : END Event execmgr 8/9/2016 9:27:02 AM 7060 (0x1B94) CExecutionRequestManager::OnServiceWindowEvent for START execmgr 8/9/2016 9:27:03 AM 4080 (0x0FF0) Auto Install is set to false. Do Nothing. execmgr 8/9/2016 9:27:03 AM 4080 (0x0FF0) Any idea what might be the issue ?

Hello all, I've upgraded my sccm server to 2012 sp1 and deployed windows 10 all went fine and applications installed without problems on the windows 10 machine. Right now i am setting my group policy right and facing a isue of windows 10 what i think need to be turned of in a domain network. You got different Privacy policy's that can send wifi passwords, account information, Keyboard recorder ( key logger) to the microsoft servers. Where and how can i set this OFF by group policy?