anyweb

Introduction Microsoft (together with a bunch of Microsoft MVP's in Seattle) have released the latest Technical Preview release of System Center Configuration Manager namely System Center Configuration Manager Technical Preview 1711. There are two main versions (of Configuration Manager) available: System Center Configuration Manager (Current Branch) System Center Configuration Manager (Technical Preview) System Center Configuration Manager (Current Branch) is designed for use in production, for managing anything from small to very large Enterprises whereas System Center Configuration Manager (Technical Preview) is for lab environments only and is limited to 10 clients. The Technical Preview releases are released monthly, and contain the latest and greatest features being trialed in the product, and usually these new features are the result of feedback from uservoice. Current Branch releases on the other hand are released only a few times per year and contain stable, tested features that are mature enough to release into production environments. System Center Configuration Manager Technical Preview 1711 is now available. This release offers the following new features: Run Task Sequence step – This release includes improvements to the new Run Task Sequence step, which runs another task sequence creating a parent-child relationship between task sequences. See the online documentation for more details about the improvements. This is currently the feature with the third highest number of votes on UserVoice Allow user interaction when installing applications as system – Now users can interact with an application installation user interface in system context even during a task sequence. This feature is a popular request on UserVoice. This release also includes the following improvement for customers using System Center Configuration Manager connected with Microsoft Intune to manage mobile devices: New options for compliance policies – You can now configure new options for compliance policies for Windows 10 devices. The new settings include policies for Firewall, User Account Control, Windows Defender Antivirus, and OS build versioning. Installing this release So how do you get Technical Preview installed ? There are two methods: Upgrade from a previous installation of Technical Preview (as shown in this guide). Do a clean install of Technical Preview 1703 (the latest TP baseline) by using the following guide and replace the base version in that guide with the TP1703 release and then upgrade. Upgrading to this release Once you have a Technical Preview release installed, in the Configuration Manager console browse to Administration, Overview, Updates and Servicing as shown below. Click on Check for Updates (in the ribbon) Next, click on the OK button. After refreshing the console, you can see the update is available. As instructed, if you want more details about what’s happening, you can read the DMPDownloader.log available in <drvletter>:\Program Files\Microsoft Configuration Manager\Logs, you can use CMTrace to do so. And refresh the console by clicking on the Refresh icon in the ribbon, you should see the update pack is downloading, and once it is downloaded the state will change to Ready to Install. Installing the update Right click the update and choose Install update pack. A wizard appears. Click Next. the Features included in the update pack will be listed. Select your client update settings and click Next accept the EULA and configure the software assurance expiration date and click through to the completion Monitoring the Upgrade At this point you should monitor the CMUpdate.log available in <drvletter>:\Program Files\Microsoft Configuration Manager\Logs, you can use CMTrace to do so. This log will detail the installation of the update pack. You should also pay attention to the following log files present in the root of C:\. CompMgrProv.Log ConfigMgrPrereq.log ConfigMgrSetup.log and after refreshing the console, the state of the update pack will change to Installing. Clicking on Show Status will give you detailed info about the state the Installation is in, it is broken down into 5 distinct phases in the top pane: Download Replication Prerequisite Check Installation Post Installation Selecting a phase will highlight what state the update is in, including what (if any) problems it has. And after a while it should progress through to the Post Installation phase, And after refreshing the console you’ll be informed that a new version is available namely version 5.00.8582.1000. and after a while the new console is installed. After Installing this version, you can check your Upgrade history by navigating to the Updates and Servicing node, and clicking on History in the ribbon. Related reading https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1711 https://cloudblogs.microsoft.com/enterprisemobility/2017/11/17/update-1711-for-configuration-manager-technical-preview-branch-available-now/

should be no problem with SCCM current branch, have you tried that ?

hi, all you have to do is mount the boot wim with DISM, inject the file (copy it) and then unmount the boot wim, i'll post an example if you need

you might also want to checkout this post, for the next time

I'd go with one server, it's much easier to manage, but refer to the following link before deciding what is appropriate for your organisation https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/mbam-25-planning-checklist

and as regards your new error it could be related to anything, for example what version of the ConfigMgr client are you installing ? stick with it, you'll get it working the error you are seeing ( Failed to create an instance of COM progress UI object. Error code 0x80040154 means... Class not registered Source: Windows ----- why, I do not know... but check your ConfigMgr client agent version for starters...

have you tried changing SKU as described here (from Mr. Niehaus) You can force it by adding a “/pkey <key>” switch to the command. For example, if you want to force it to upgrade to Windows 10 Enterprise, use “/pkey NPPR9-FWDCX-D2C8J-H872K-2YT43”.

can you attach your smsts.log files please ?

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

you would have to configure that requirement in Intune first, and then see how it's applied on a client computer, then and only then should you modify the MSI to match your requirements, I have not tested that scenario though but i'd be happy to help you with it

glad you got it resolved ! my messenger inbox was full, but i've emptied it now

i see the scaling is crazy in that screenshot, and i bet if you log off and log back on again it will look better, but alternatively you can adjust the dpi settings in the wrapper to fix this, if you want i can remote in via teamviewer and help you with this, just pm me your details

i guess you'll have to change the SKU to match the version you are installing as part of the installation, you can do that as documented here but i don't know if OEM is covered https://blogs.technet.microsoft.com/mniehaus/2017/10/09/changing-between-windows-skus/ can you please tell me what version of Windows 10 are you upgrading from (home/pro ?)

as regards the SUM collections they are just sample collections that you can use for Windows servicing or Software Update Deployment, you decide in relation to the DPI settings, you may need to adjust/change the values to suit the hardware that you have, I don't have access to every device so what I tested works for me on most devices, feel free to post your solution for those DPI's here for others and mention the hardware you tested it on thanks for trying it out and sticking with it ! cheers niall

ok, apologies for the delay my lab died and i had to re-import all my vm's but it's running again now and i tested the script, you got the buggy one (sorry), i've re-attached the working one, please try it out and let me know if there's any problems or questions, i've tested it in a CM environment with no extra collections added and it worked just fine as you can see below, give it a try ! cheers niall

what os are you upgrading from ?

well in my version it logs that it's deleting the scheduled task, when did you download the msi, perhaps you should retry the download

i'll look at the script tomorrow if i get time and provide feedback, it's a while since i wrote it, and... I recently added that script after making some changes to the wrapper, so i may have uploaded the wrong script, but basically the SUM collections are Software Update Management,

the script works for me every time in a lab, did you edit it in any way ?

the error above translates to " A network error interrupted the operation. Source: Windows ----- " do you get an ip in WinPE ? did you try adding network drivers for the hardware involved to your boot image ? this script will help you identify if you have missing drivers in the boot image and will inform you if so

no problem, if you still have issues then please post the exact error message you get so we can try and help

1. the 4 hours is to give the user time to finish their PowerPoint or meeting, and then start the upgrade with loads of time to spare, but at the same time to give them a sense of urgency 2. set them whatever way you want 3. VPN's can cause upgrade's to fail (lack of connection), hence the vpn check, it's better to do the upgrade in the office to force it to run quickly I open a powershell cmd prompt on a vm, and start the powershell start... command to kick off the hta, that's a manual process but it allows you to test the flow so that you are happy with it cheers niall

heh well good luck with that, if you want to manage servers then most people do that with SCCM, by installing the client agent on the servers to do tasks (application install, gathering data etc) and software update management, there's a whole bunch of guides here on windows-noob to get you started with that, here for example

hi and welcome, what is your goal here ? to manage a few desktops or image them, or what ?

really ? it worked for me when I tested it, what does the log tell you ?