Leaderboard

Thanks for your guidance, it is a very helpful! I did all the steps on my test infrastructure, though I had a reduced set of virtual machines. It seems to me that there is an error in section 5 (maybe my comment will help other people) You suggest to execute the command: certutil -f -dspublish "E: \ ROOTCA_windows noob Root CA.crt" RootCA Where RootCA , as you write, is the host name of offline Root CA, however certutil helps us: CertUtil [Options] -dsPublish CertFile [NTAuthCA | RootCA | SubCA | CrossCA | KRA | User | Machine] ... CertFile - certificate file to publish NTAuthCA - Publish cert to DS Enterprise store RootCA - Publish cert to DS Trusted Root store SubCA - Publish CA cert to DS CA object CrossCA - Publish cross cert to DS CA object ... So RootCA in this case is not the host name here, but the store name. Your host name matches the store name, and your command has been executed. My Root CA name was different, and when I will have tried to execute the command certutil -f -dspublish "C:\from_RCA\RCA01_My-CA.crt" RCA01 i got an error CertUtil: -dsPublish command FAILED: 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER) CertUtil: The parameter is incorrect. however command certutil -f -dspublish "C:\from_RCA\RCA01_My-CA.crt" RootCA performed correctly. Next command in your manual certutil -f -dspublish "E: \ windows noob Root CA.crl" RootCA is correct, because to publish CRL you must specify the host name: CertUtil [Options] -dsPublish CRLFile [DSCDPContainer [DSCDPCN]] .... CRLFile - CRL file to publish DSCDPContainer - DS CDP container CN, usually the CA machine name

Introduction This is part 3 in a series of guides about cloud attach in Microsoft Endpoint Manager, with the aim of getting you up and running with all things cloud attach. This part will focus on creating a Cloud Management Gateway (CMG). This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. Paul is 4 times Enterprise Mobility MVP based in the UK and Niall is 10 times Enterprise Mobility MVP based in Sweden. In part 1 we configured Azure AD connect to sync accounts from the on premise infrastructure to the cloud. In part 2, we prepared Azure resources for the Cloud Management Gateway, in this part we'll create the cloud management gateway and verify everything is running smoothly. A Cloud Management Gateway gives you a whole bunch of new abilities for managing, imaging computers, escrowing BitLocker keys and delivering software, updates and policy to remote based internet enabled clients. Cloud attach - Endpoint Managers silver lining - part 1 Configuring Azure AD connect Cloud attach - Endpoint Managers silver lining - part 2 Prepare for a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 3 Creating a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 4 Enabling co-management Cloud attach - Endpoint Managers silver lining - part 5 Enabling compliance policies workload Cloud attach - Endpoint Managers silver lining - part 6 Enabling conditional access Cloud attach - Endpoint Managers silver lining - part 7 Co-managing Azure AD devices Cloud attach - Endpoint Managers silver lining - part 8 Enabling tenant attach Step 1. Create Cloud Management Gateway Note: The screenshots here were taken in Configuration Manager version 2010 so some features such as Virtual Machine Scale Set available in later releases may not be visible. In the Configuration Manager console, go to the Administration workspace, expand Cloud Services, and select Cloud Management Gateway. Right click and choose Create Cloud Management Gateway. Click on Sign in and when prompted, use the credentials of an Azure subscription administrator account. The wizard will auto-populate the remaining fields from the information stored during the Azure AD integration prerequisite. If you own more than one subscription, select the Subscription ID of the desired subscription using the drop down menu. Specify the Azure environment for this CMG. The options in the drop-down list may vary depending upon the deployment method. The screenshot below was taken from ConfigMgr version 2010 which we used at the time of writing this lab. And the screenshot below shows the new option to decide how you want to deploy your cloud services. Virtual Machine Scale Set which is available as a production feature in ConfigMgr version 2107 and later versions, prior to that verion is was available as a pre-release feature. For details of the difference in choosing Virtual Machine Scale Set versus Cloud service (classic) see Paul's post here. To change the size of your Virtual Machine Scale Set see this post. On the Settings page of the wizard, click Browse and choose the .pfx file you created in step 5 of this blog post for the Cloud Management Gateway server authentication certificate. The name from this certificate populates the required Service FQDN and Service name fields. Enter the password when prompted Next, click the Region drop-down menu to choose the Azure region for your Cloud Management Gateway. For the Resource Group, if you choose Use existing, then select an existing resource group from the drop-down list. The selected resource group must already exist in the region you selected above. If you choose Create new, then enter the new resource group name. In the VM Instance field, enter the number of VMs for this service. The default is one, but you can scale up to 16 VMs per CMG. Note: If you select an existing resource group and it is in a different region than the previously selected region, the Cloud Management Gateway will fail to provision. Click on Certificates to add client trusted root certificates. Add all of the certificates in the trust chain, so for example if you have certificates from an Issuing CA (Intermediate CA) and Offline Root CA (Trusted Root CA) then include both certificates. An example of that PKI setup is here. Here were the certificates we used (Trusted Root and Issuing). Start with the Trusted Root first. If you need to use an Intermediate certificate from an Issuing CA then you will get a popup stating that it's not a valid root, it is safe to ignore that popup as long as you do include the trusted root. Here are our certs listed after adding them, you may have more (or less) depending on your PKI setup. Note: By default, the wizard enables the option to Verify Client Certificate Revocation. A certificate revocation list (CRL) must be publicly published for this verification to work. That would be handled by the webserver in my PKI guide. Configure your desired Alerts Review the summary and if you need to make changes click Previous, otherwise it's time to start monitoring logs. Complete the wizard, close it and you should see the CMG is in a state of Provisioning. And open the CloudMgr.log, below you can see it's starting the task of creating the CMG. After a while the status changes to Upgrading (click Refresh to see the change). And when the log file reads RanToCompletion, you can assume it's ready. As reflected in the console. Step 2. Add the CMG connection point role The CMG connection point is the site system role for communicating with the CMG. In Servers and Site System Roles, right click on your on-premise site server and choose Add Site System Roles. If you need to use a Proxy to communicate with the CMG then configure it here. On the System Role Selection page of the Add Site System Roles Wizard, select Cloud management gateway connection point. Then select the Cloud management gateway name to which this server connects. The wizard shows the region for the selected CMG. Continue through the wizard until completion, and then close the wizard. Next, open the SMS_Cloud_ProxyConnector.log to review things. You might see some connection issues listed, fear not, it will retry in 60 seconds. If the lines in red don't go away you might want to take a glance at the required ports for the CMG connection point. Note: For the service connection point the Server: Azure entry relates to management.azure.com. The CMG connection point ports 10140-10155 and 10124-10139 are incremental per VM that you assign when creating the CMG. So, if you build 2 VM instances, you will use ports 10140, 10141 and 10124, 10125. You need to assign the rule to name of the CMG to which your clients resolve, so we would enter cloudattachcmg.azurenoob.com in our rule. For the blob storage rule, you need to enter the prefix of the CMG name plus .blob.core.windows.net in your rule. So we would enter cloudattachcmg.blob.core.windows.net in our firewall rule. Once the connection is made you'll see the following in the log file "Starting to connect to Proxy server cloudattachcmg..." And when the connection is complete you can see it reflected in the console in the Connection Points tab of the CMG, it should have a Connection status of Connected. Step 3. Configure client-facing roles for CMG traffic Next we need to configure the management point and software update point site systems to accept CMG traffic. You should perform this procedure on the primary site, for all management points and software update points that service internet-based clients. In the Configuration Manager console, go to the Administration workspace, expand Site Configuration, and select the Servers and Site System Roles node. Select Management point from the list. In the Management point properties sheet under Client Connections, check the box next to Allow Configuration Manager cloud management gateway traffic. Apply the changes and close the Management Point properties. Next, open the Software Update Point role properties. Check the box next to Allow Configuration Manager cloud management gateway traffic in WSUS Configuration. Step 4. Configure client settings In the Administration node of the console, select Client Settings, select Default client settings, and configure the Cloud settings. Verify that Enable clients to use a cloud management gateway is set to Yes. If you don't want this to apply to all of your clients in the hierarchy, create a custom client device settings instead and deploy it to a device collection containing the clients you want enabled. Step 5. Verify by running the connection analyzer Now that you've configured the cloud management gateway, it's time to verify that everything is OK. In the Administration node of ConfigMgr, select Cloud Services, then select Cloud Management Gateway. Click on Connection Analyzer in the ribbon. At the Cloud management gateway connection analyzer screen, click Sign in and use the azure credentials you used to set this up. Once done, click on Start. If everything went according to plan it should look like this. If you had a problem, it might look like this...If it does, highlight the red x to see more details of the issue. and in this particular case we had to upgrade the cmg (timing issue perhaps ?) by clicking on Synchronize configuration in the ribbon. Notice how it says Upgrading. You can also refer to the CloudMgr.log to see it upgrading the configuration in such a scenario. That's it for this part, you now have a CMG in place and are ready for our next part of our cloud attach series. Related reading CMG FAQ - https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/cloud-management-gateway-faq Data flow for CMG - https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/data-flow Managing remote clients with a CMG - https://techcommunity.microsoft.com/t5/configuration-manager-blog/managing-remote-machines-with-cloud-management-gateway-in/ba-p/1233895

I'm glad you got it sorted

take a look at my two posts here, they cover everything you need to convert to https, they'll cover a bit more than Justins excellent video, so do please verify you didn't miss anything How can I configure System Center Configuration Manager in HTTPS mode (PKI) - Part 1 How can I configure System Center Configuration Manager in HTTPS mode (PKI) - Part 2 also, keep in mind that certs can expire, and when they do you'll have issues, like this https://www.niallbrady.com/2020/08/16/how-can-i-replace-an-expired-iis-certificate-in-a-pki-enabled-configmgr-environment/ if you want to really test PKI is working then try pxe boot (operating system deployment), if it fails you'll see it failing quickly in the logs, and that'll be a clue that you've missed something, also, on PKI managed clients, your configmgr client agent should report that the client is PKI, like this...

try setting it like this

Hi, Well guess what, it finally appeared after 5 days, I did not change anything since and this morning that appeared on the computer: Thanks to both of you for you answers and help! Have a nice day!

Introduction Sometimes you need to install Windows features that normally need internet access (to install other components), language packs installed today are done in a modular and different format from previous years. In previous times you could simply install a language pack for the associate language and all was good, now there are additional components that also need to be installed otherwise Windows will attempt to download them from the internet (and notify you via the notification center if it cannot). I needed to install Windows 10 LTSC version 2019 in an offline environment (with no internet access) and I also needed to configure language pack settings and configure keyboard layout. I came up with a solution that works for me and I thought I'd share it. You might know of a simpler or better way, if so feel free to comment. Note: The LTSC (Long Term Servicing Channel) version of Windows 10 is suited for special environments, and environments without Internet certainly are special. I've even verified that the equivalent version of Windows 10 (aka Windows 10 version 1809) behaves the same way, in fact the screenshots used here are from Windows 10 1809, I didn't import LTSC into my lab yet. I've also tested this method with Windows 10 version 2004 (and the associated version 2004 LP and FOD files and it works perfectly ! Step 1. Get the feature on demand packages Normally if you install a language pack on a Windows 10 computer with valid internet, it will automatically download the associated features on demand for that language and those can include: Display language Text-to-speech Handwriting Speech recognition Typing You can see these additional items listed in the screenshot below. Depending on the language pack capabilities, some will have all of these and some will have only a few. Most of these components (features on demand or FOD packages) can be found on the features on demand ISO for the respective operating system and you can download those ISOs from the Volume License Servicing Center (VLSC) website or go to Visual Studio downloads (formally MSDN). Below you can see some of the FOD packages listed on the mounted ISO. There are FOD packages for different types of function within Windows and the packages I was most interested in were any related to language (specifically). You may find that you want to install additional FODs for your particular solution. If you scroll down the long list of FOD packages you'll see some that begin with Microsoft-Windows-LanguageFeatures, and they are sorted by country code (where applicable) into the following sections. Microsoft-Windows-LanguageFeatures-Basic Microsoft-Windows-LanguageFeatures-Fonts Microsoft-Windows-LanguageFeatures-Handwriting Microsoft-Windows-LanguageFeatures-OCR Microsoft-Windows-LanguageFeatures-Speech Microsoft-Windows-LanguageFeatures-TextToSpeech such as below. This was my first clue to solve this. I decided to copy all the LanguageFeatures FOD packages from the ISO to somewhere local. The next thing I found on the ISO was Metadata, so I copied that also. Step 2. Get the Language packs Finally, there are also Language Pack ISOs available for download for your respective version of Windows 10, and on that ISO are larger cab files containing the client language pack for each language that is available. You can find the language packs in the architecture folder on this ISO. They'll look something like this. Step 3. Sort the downloads by country code Now that you've got the necessary files, you need to decide which languages you are going to support during OSD and sort them into their own respective folders. I copied language specific FOD packages and the client language pack for each language I was interested in into it's own separate folder like below (sv-SE for Sweden), and then copied those folders onto my package sources folder on the ConfigMgr server. Note that some languages may have more (or less) FOD packages available than others, so copy all that are available on the ISO and you should be good to go. The first cab file listed below is the Client Language Pack from the Language Pack ISO and the remaining 4 cabs are from the FOD ISO. Next create another folder with the Metadata files within it. Step 4. Create packages In ConfigMgr, create a separate package for each language you intend to add support for and point it to the folder containing the Client Language Pack and FOD packages. Once you've created all the language pack packages, don't forget to create the Metadata package. Distribute the packages to your distribution points. Step 5. Import the task sequence To save you a lot of effort all you need to do is import my task sequence and then modify the package references to suit your environment. Note: This is an MDT integrated task sequence so if you want to use it please integrate MDT with ConfigMgr. You will get messages about missing content during the import, choose 'ignore dependancies' and it will import the task sequence steps anyway. However, you must then step through each step in the task sequence that references a package, and point it to the equivalent package on your ConfigMgr environment. After importing the task sequence, make sure to add your language packages (and metadata) to the appropriate steps that reference them otherwise this won't work, pretty much all of the xcopy steps will need a package attached to them. Download the following, and import into ConfigMgr. Windows 10 LTSC language packs without internet.zip Step 6. A quick look at the task sequence logic The task sequence works by first setting a variable, called Location. You can set this as a step in the task sequence dynamically based on various inputs (such as DHCP IP address, gateway, computer variable, collection variable). That I leave up to you, I've forced this example to use Sweden as the location. Next, it dynamically sets Language specific variables based on the Location set previously. You need to add one of these dynamic groups for each language you intend to support. The below screenshot shows two languages configured but you could have multiple. Next (1) it injects the system, user, locale specific settings based on the dynamic variables set above. SysLocale UserLocale InputLocale Thee next group (2) copies the en-US language pack+FOD packages, and metadata. This is needed if you want to be able to switch languages via the input switch in the task tray (language bar). Next, it dynamically downloads (3) the FOD package containing the needed files to add features on demand plus the language pack for the language you are adding support for. It then uses a bunch of DISM commands (4) to inject the necessary FOD packages. After that it sets some reg-keys (5) to deal with known issues relating to language packs cleanup before adding some more steps to allow both languages (en-US and sv-SE in this example) to display on the login screen using the input methods switch. Step 7. Viewing the result After all that hard work you'll want to see the end result. In this lab I've disabled internet access by simply powering off my Smoothwall (which controls internet to the lab). We can see in WinPE that there is no internet. After selecting the task sequence it downloads the Operating System, applies it and then starts injecting the cab files and other dism operations. Below you can see it inject one of the FOD packages And below it's injecting the Client Language Pack, all of this is dynamic based on the Location variable. After installation is complete the login screen shows no internet in the LAN connection, but the language is in Swedish. When you attempt to login you'll see the language bar, awesome. And after logging in, you will see that your chosen language pack is installed along with the necessary FOD packages, automatically and dynamically even without internet ! Awesome or what ! And of course you can use PowerShell to verify the installation of your language pack with Get-WinUserLanguageList. Windows 10 version 2004 What about Windows 10 version 2004 ? it works perfectly using this exact same method, just switch out the Operating System wim file with the 2004 version and replace the FOD and LP packages with the correct version, see below. Recommended reading Add language packs to Windows - https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-language-packs-to-windows Known issues - https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/language-packs-known-issue Available languages - https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/available-language-packs-for-windows Language and region feature on demand - https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/features-on-demand-language-fod https://docs.microsoft.com/en-us/powershell/module/international/get-winuserlanguagelist?view=win10-ps

interesting problem, are you setting this variable to true as a matter of interest ? SMSTSDisableStatusRetry In disconnected scenarios, the task sequence engine repeatedly tries to send status messages to the management point. This behavior in this scenario causes delays in task sequence processing. Set this variable to true and the task sequence engine doesn't attempt to send status messages after the first message fails to send. This first attempt includes multiple retries. When the task sequence restarts, the value of this variable persists. However, the task sequence tries sending an initial status message. This first attempt includes multiple retries. If successful, the task sequence continues sending status regardless of the value of this variable. If status fails to send, the task sequence uses the value of this variable. and have you tried setting this variable after the reboot ? SMSTSMP Use this variable to specify the URL or IP address of the Configuration Manager management point. https://docs.microsoft.com/en-us/mem/configmgr/osd/understand/task-sequence-variables

There's an official MS doc update on this now at https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/how-to-enable-bitlocker-by-using-mbam-as-part-of-a-windows-deploymentmbam-25). No clue how many companies are potentially affected by this ... but seriously, for anybody reading this post ... if you're currently using Invoke-MBAM with ConfigMgr's native BitLocker Management, just get it completely out of your task sequences now. Even if you're not on 2103 yet ... get it out so you don't get hit by this if / when you do upgrade to 2103. It's frustrating there's no supported way to escrow recovery info during OSD but trust me, you do not want to have a large environment get hit by this issue. If you are on 2103+ and have used Invoke-MBAM in task sequence scenarios since upgrading to 2103 ... I'd recommend you get in a support case with MS ASAP and then you too can join in the fun of waiting to see if and how your database / server WMI / client WMI can be salvaged.

Text=ERROR_WINHTTP_NAME_NOT_RESOLVED dns or network issues ? have you reviewed the required ports and other configuration that we've blogged about here ?

normally what I do is uninstall the existing ADK, restart the server, then install the latest applicable ADK, but it all depends on what version of ADK you have installed, and whether it's compatible with 2103 or not here's the list of supported ADK's https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/support-for-windows-10#windows-10-adk

Introduction This multi-part guide will show you how to install the latest baseline version of Configuration Manager from Microsoft. The latest available baseline version is System Center Configuration Manager (Current Branch) version 1902 as of April the 10th 2019. I blogged how to upgrade to 1902 here. This guide is aimed a new installations of SCCM. Baseline media is used to install new ConfigMgr sites or to upgrade from supported versions, for more information about baseline media please see my blog post here. This series is broken down into the following parts:- Part 1 - Get the lab ready, configure ADDS Part 2 - Join CM01 to Domain, add users, create the Systems Management container, delegate permission Part 3 - Role and Feature installation, installation of WDS and ADK Part 4 - Configure and install SQL Server 2017 Part 5 - Configure and install SCCM 1902 Current Branch Part 6 - Create device collections Part 7 - Configuring discovery (This part) Part 8 - Configuring boundaries You can use this multi-part guide to get a hierarchy up and running on Windows Server 2019 using SQL Server 2017. The driving concept behind this series of guides is to help you through all the steps necessary to get a working Configuration Manager Primary site installed (for lab use) using manual methods or automated using PowerShell. This gives you the power to automate the bits that you want to automate, while allowing you to manually do other tasks when needed. You decide which path to take. PowerShell knowledge is desired and dare I say required if you are in any way serious about Configuration Manager. I will show you how to do most steps via two methods shown below, it's up to you to choose which method suits you best but I highly recommend automating everything that you can, using PowerShell. Method #1 - Do it manually Method #2 - Automate it with PowerShell When testing your scripts using PowerShell you can actually use PowerShell ISE help to figure out what commands a cmdlet accepts and build your script that way, here's an example. In this post you will learn about configuring discovery. Planning for discovery in ConfigMgr is an important step while configuring your sites and hierarchies. You need to discover objects in locations that you select and these discovered resources are what you want to manage (can be devices and/or users). These discovered resources can be targeted with software and/or get the ConfigMgr client agent installed via Client Push functionality. Discovery within System Center Configuration Manager (Current Branch) has 7 different discovery methods listed below, the first 6 of which are user configurable, the last method, Server Discovery is not user configurable. Active Directory Forest Discovery Active Directory Group Discovery Active Directory System Discovery Active Directory User Discovery Heartbeat Discovery Network Discovery Server Discovery When a discovery method successfully finds a new resource, discovery puts information about that resource into a file that is called a discovery data record (DDR), which is processed by a primary or central administration site. Processing of a DDR creates a new record in the site database for newly discovered resources, or updates existing records with the DDRs new information. [source: doc.microsoft.com] Downloads Note: in order to download these scripts you must be a logged on member of windows-noob.com. The scripts used in this part of the guide are available for download here. Unzip to C:\Scripts. The scripts are placed in the corresponding folder (Part 1, Part 2 etc) and sorted into which server you should run the script on (DC01 or CM01). Scripts.zip Step 1. Enable Active Directory Forest Discovery Note: Perform the following on the Configuration Manager server (CM01) as a Local Administrator Unlike other Active Directory discovery methods, Active Directory Forest Discovery does not discover resources that you can manage. Instead, this method discovers network locations that are configured in Active Directory. It can convert those locations into boundaries for use throughout your hierarchy. When this method runs, it searches the local Active Directory forest, each trusted forest, and each additional forest that you configure in the Active Directory Forests node of the Configuration Manager console. You can use Active Directory Forest Discovery to: Discover Active Directory sites and subnets, and then create Configuration Manager boundaries based on those network locations. Identify supernets that are assigned to an Active Directory site. Convert each supernet into an IP address range boundary. Publish to Active Directory Domain Services (AD DS) in a forest when publishing to that forest is enabled. The specified Active Directory Forest Account must have permissions to that forest. Method #1 – Do it manually In the Configuration Manager console, click on Administration and select Hierarchy Configuration, click on Discovery Methods. The first discovery method listed is Active Directory Forest Discovery. To discover Active Directory network locations and convert those locations into boundaries right click Active Directory Forest Discovery for the primary site and right click, choose Properties. The General window appears with one option, Enable Active Directory Forest Discovery. Enable that option and two more choices are revealed: Automatically create active directory site boundaries when they are discovered Automatically create IP address range boundaries for IP subnets when they are discovered. Tip: Selecting both options above is fine in a LAB. In Production however, you should consider only selecting to discover IP address ranges. For clarification about this point please review this post from Jason Sandys (Enterprise Mobility MVP) about why IP Subnet Boundaries are EVIL Select the second option (Automatically create IP address range boundaries for IP subnets when they are discovered) and leave the default schedule for every 1 weeks. Click Apply, you'll be prompted if you want to run a discovery as soon as possible, answer Yes. Tip: If you want to review the discovery of objects via this discovery method, you can use CMTrace to open the ADForestDisc.log file. The log file will be located in in the <InstallationPath>\LOGS folder. Note that the log file will not appear immediately after enabling this discovery method, it can take a few minutes before it appears. When publishing is enabled for a forest and that forests schema is extended for Configuration Manager, the following information is published for each site that is enabled to publish to that Active Directory forest: SMS-Site-<site code> SMS-MP-<site code>-<site system server name> SMS-<site code>-<Active Directory site name or subnet> To verify that you've enabled publishing browse to Administration, Site Configuration, Sites, and check the properties of your Primary site server. Click on the Publishing tab. Method #2 - Automate it with PowerShell To enable Active Directory Forest Discovery automatically, use the Configure Forest Discovery.ps1 PowerShell script. 1. Copy the script to C:\Scripts on CM01 2. Edit the variables (lines 28-37) as desired before running.  3. Start Windows PowerShell ISE as Administrator and run the script by clicking on the green triangle. Step 2. Enable Active Directory Group Discovery Note: Perform the following on your ConfigMgr server as a user with Full Administrator permissions in the ConfigMgr console. You can use Active Directory Group Discovery to search Active Directory Domain Services (AD DS) to identify the group memberships of computers and users. This discovery method searches a discovery scope that you configure, and then identifies the group memberships of resources in that discovery scope. By default, only security groups are discovered. However, you can discover the membership of distribution groups when you select the checkbox for the option Discover the membership of distribution groups on the Option tab in the Active Directory Group Discovery Properties dialog box. When you discover a group, you can also discover limited information about its members. Note: This does not replace Active Directory System Discovery or Active Directory User Discovery and is usually insufficient to build complex queries/collections or to serve as the bases of a client push installation. Active Directory Group Discovery can discover the following information: Groups Membership of Groups Limited information about a groups member computers and users, even when those computers and users have not previously been discovered by another discovery method Tip: This step assumes you want to discover resources recursively in the windowsnoob OU. Therefore, it may be necessary to move servers into their respective OU which is a child OU under the windowsnoob OU created in this guide otherwise they will not be discovered by this discovery method. You can do that via Active Directory Users and Computers on DC01. Method #1 – Do it manually In the ConfigMgr console, in the Administration workspace, select Hierarchy Configuration, then select Discovery Methods and right click Active Directory Group Discovery and choose properties. The Active Directory Group Discovery Properties window appears. Select the option to Enable Active Directory Group Discovery and click on Add to see two more choices, Groups and Location. These options are explained below: Groups: Use groups if you want to search one or more specific Active Directory groups. You can configure the Active Directory Domain to use the default domain and forest, or limit the search to an individual domain controller. Additionally, you can specify one or more groups to search. If you do not specify at least one group, all groups found in the specified Active Directory Domain location are searched. Location: Use a location if you want to search one or more Active Directory containers. This scope option supports a recursive search of the specified Active Directory containers that also searches each child container under the container you specify. This process continues until no more child containers are found. Note: When you configure a discovery scope, select only the groups that you must discover. This is because Active Directory Group Discovery attempts to discover each member of each group in the discovery scope. Discovery of large groups can require extensive use of bandwidth and Active Directory resources. Select Location from the drop down menu. Give it a name like Active Directory Group Discovery - P01 and select browse to decide where to recursively search. In this example I select the previously created windowsnoob Organizational Unit (OU) which will contain your servers, users, computers and devices. Click OK to accept the Add Active Directory Location screen changes, next, click on the Polling schedule tab and decide what is appropriate for your setup, the default for full discovery is 7 days and you can enable Delta Discovery (enabled by default). This discovery method finds resources in Active Directory Domain services that are new or modified since the last discovery cycle in the time interval specified (default is 5 minutes). Next, you can review the three options on the Options tab and click Apply when ready and answer Yes to running the full discovery when prompted. Tip: If you want to review the discovery of objects via this discovery method, you can use CMTrace to open the adsgdis.log file. The log file will be located in in the <InstallationPath>\LOGS folder. Method #2 - Automate it with PowerShell To enable Active Directory Forest Discovery automatically, use the Configure Group Discovery.ps1 PowerShell script. 1. Copy the script to C:\Scripts on CM01 2. Edit the variables (lines 28-50) as desired before running.  3. Start Windows PowerShell ISE as Administrator and run the script by clicking on the green triangle. Step 3. Enable Active Directory System Discovery Note: Perform the following on your ConfigMgr server as a user with Full Administrator permissions in the ConfigMgr console. You can use Active Directory System Discovery to search the specified Active Directory Domain Services (AD DS) locations for computer resources that can be used to create collections and queries. You can then install the client to discovered computers by using client push installation. To successfully create a discovery data record (DDR) for a computer, Active Directory System Discovery must be able to identify the computer account and then successfully resolve the computer name to an IP address. By default, Active Directory System Discovery discovers basic information about the computer including the following: Computer name Operating system and version Active Directory container name IP address Active Directory site Last Logon Timestamp Method #1 – Do it manually In the ConfigMgr console, in the Administration workspace, select Hierarchy Configuration, then select Discovery Methods and right click Active Directory System Discovery and choose Properties, place a check mark in Enable Active Directory System Discovery. Click on the yellow starburst to add some Active Directory containers. For path click on browse and browse to the location you want to discover systems in. Tip: You can add several locations by repeating this process and selecting different locations, but only add the locations you need to add as you don't want to generate unnecessary network and CPU bandwidth. On the Polling schedule tab, stick to the defaults and then select the Active Directory Attributes tab, if you want to add an attribute to discover select one from the list and choose Add >> in the example below you are adding an Active Directory attribute called msTPM-ownerinformation. There are many attributes to choose from, use only the ones you need to get your job done. Once you are happy, click Apply and Ok and answer Yes to run a full discovery as soon as possible. Tip: If you want to review the discovery of objects via this discovery method, you can use CMTrace to open the adsysdis.log file. The log file will be located in in the <InstallationPath>\LOGS folder. Method #2 - Automate it with PowerShell To enable Active Directory System Discovery automatically, use the Configure System Discovery.ps1 PowerShell script. 1. Copy the script to C:\Scripts on CM01 2. Edit the variables (lines 28-50) as desired before running.  3. Start Windows PowerShell ISE as Administrator and run the script by clicking on the green triangle. Step 4. Enable Active Directory User Discovery Note: Perform the following on your ConfigMgr server as a user with Full Administrator permissions in the ConfigMgr console. Use Configuration Manager Active Directory User Discovery to search Active Directory Domain Services (AD DS) to identify user accounts and associated attributes. You can view the default list of object attributes returned by Active Directory User Discovery, and configure additional attributes to be discovered in the Active Directory User Discovery Properties dialog box on the Active Directory Attributes tab. By default, Active Directory User Discovery discovers basic information about the user account including the following: User name Unique user name (includes domain name) Domain Active Directory container names Method #1 – Do it manually In the ConfigMgr console, in the Administration workspace, select Hierarchy Configuration, then select Discovery Methods and right click Active Directory User Discovery and choose Properties. Place a checkmark in Enable Active Directory User Discovery as shown below. Next, click on the yellow starburst to add some active directory locations to discover users. You can configure the Polling tab and Active Directory Attributes tab settings if you wish, then click Apply and answer Yes to Run a Full Discovery now. Tip: If you want to review the discovery of objects via this discovery method, you can use CMTrace to open the adusrdis.log file. The log file will be located in in the <InstallationPath>\LOGS folder. The observant amongst you might notice the yellow warnings, they are nothing to worry about, it's simply informing you that it cannot find the 3 optional attributes on these users that were defined (using the PowerShell script below). Method #2 - Automate it with PowerShell To enable Active Directory User Discovery automatically, use the Configure User Discovery.ps1 PowerShell script. 1. Copy the script to C:\Scripts on CM01 2. Edit the variables (lines 28-44) as desired before running.  3. Start Windows PowerShell ISE as Administrator and run the script by clicking on the green triangle. Step 5. Review discovered resources in the console Note: Perform the following on your ConfigMgr server as a user with Full Administrator permissions in the ConfigMgr console. At this point you can refresh the view in Discovery Methods to see which methods are enabled. You did not enable Network discovery as it can impact network bandwidth, read more about that method here. Next, let's see what has been discovered. In the ConfigMgr console, in the Assets and Compliance workspace, select Users, the discovered Users should appear. In the Assets and Compliance workspace, select User Collections, and double click on All User Groups, the discovered User Groups should appear. In the ConfigMgr console, in the Assets and Compliance workspace, select Devices, then select All Systems, the discovered Systems should appear. If any that you expected do not appear, adjust your search criteria in the discovery methods and try again. Note: If you are wondering why DC01 does not appear it is because that server is placed under the Domain Controllers container in Active Directory and that container path was not added to any system discovery method. Recommended reading Set-CMDiscoveryMethod https://docs.microsoft.com/en-us/powershell/module/configurationmanager/set-cmdiscoverymethod?view=sccm-ps Discovery methods - https://docs.microsoft.com/en-us/sccm/core/servers/deploy/configure/about-discovery-methods Summary In this guide you configured Discovery methods in System Center Configuration Manager (Current Branch) to discover resources that you want to manage. You did this either manually or in an automated fashion using PowerShell. In the next part of this new series you will configure Boundaries

have you reviewed this video yet ? if not skip through it to see what you've missed, it's based on ConfigMgr 1910 but it'll give you some clues hopefully

I can definitely confirm that this guide works. In truth, there aren't many alternative ways to install this, just a few. But it would be practically the same with hopefully the same result. Do not install the PKI on DC and for simlpe deplyoments forget the OID and use the standard one.

Make sure the MW is ENABLED. If you have these configured, but the checkbox is not checked, the MW is disabled and ignored. I was able to find this by running this report : Monitoring=> Overview=> Reporting => Reports =>Software Distribution -Collections => Maintenance windows available to a specified Client Here I saw that the MW was DISABLED, et voila, I had the explanation why my clients ignored the MW.

This first thing you are going to what to do is understand where the data that you want existing within CM. These two links will help you with that. https://docs.microsoft.com/en-us/mem/configmgr/develop/core/understand/sqlviews/software-updates-views-configuration-manager https://www.informit.com/store/system-center-configuration-manager-reporting-unleashed-9780134466811 .

this site will show you how to create the .ISO then use rufus to put the .iso on boot media.. I use USB drives http://www.sccm.ie/configure-sccm-2012/17-create-a-boot-image-for-os-deployment-without-pxe-environment

This series is comprised of different parts, listed below. Part 1 - Introduction and server setup Part 2 - Install and do initial configuration on the Standalone Offline Root CA Part 3 - Prepare the HTTP Web server for CDP and AIA Publication Part 4 - Post configuration on the Standalone Offline Root CA Part 5 - Installing the Enterprise Issuing CA Part 6 - Perform post installation tasks on the Issuing CA Part 7 - Install and configure the OCSP Responder role service Part 8 - Configure AutoEnroll and Verify PKI health (this part) In part 1 of this series, you configured your LAB for a 2 tier PKI hierarchy running on Windows Server 2016. You used PowerShell to create some virtual machines, and then installed Windows Server 2016, Windows 10 Enterprise version 1803 and optionally Smoothwall 3.1 before configuring the IP address scheme and Computer Names on the virtual machines. Finally you configured ADDS on DC01 so that you have a working Domain Controller for the rest of this LAB. In part 2 you installed and did the initial configuration on the Standalone Offline Root CA. In part 3 you prepared the HTTP Web Server for CDP and AIA Publication and you created a DNS record for the publicly available web server. In part 4 you performed post configuration on the Standalone Offline Root CA to set certificate revocation list (CRL) period registry settings using CertUtil, and then enabled object access Auditing and finally, you configured three locations for the Authority Information Access (AIA) and four locations for the Certificate revocation list Distribution Point (CDP), again using CertUtil. In part 5 you joined the IssuingCA computer to the windowsnoob domain before creating a new CAPolicy.inf file which was customized for the Issuing CA role. Next, you published the Root CA Certificate and CRL (both to Active Directory and the HTTP web server) and you installed the Enterprise Issuing CA before submitting a request to the StandAlone Offline Root CA. Next you installed the Issuing CA Certificate using the response files from the StandAlone Offline Root CA on the removable media. In part 6, you performed post installation and configuration of the IssuingCA server by configuring Certificate Revocation and CA Certificate Validity Periods, you then enabled auditing on the CA server, and configured the AIA and CDP. In part 7 you installed and configured the OCSP responder role service on the web server. Now you will configure Auto Enrollment and Verify PKI health. Step 1.Configure a GPO for Auto Enrollment Logon to to the Domain Controller (DC01) as windowsnoob\Administrator. Click Start, click Run, and then type gpmc.msc and press enter. Expand Forest, expand Domains, expand windowsnoob.lab.local, and then expand Group Policy Objects. Right click Default Domain Policy, then click Edit. Under Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, and then expand Public Key Policies. Select Certificate Services Client - Auto-Enrollment, right click and choose Properties. Change it from Not Configured to Enabled and enable the following 2 options. Renew expired certificates, update pending certificates, and remove revoked certificates Update certificate that use certificate templates As shown here. Click Apply when done, and close the Group Policy Management Editor and then close the Group Policy Management Console. Step 2. Configure AutoEnrollment for Workstation Authentication on the Issuing CA Ensure that you are logged on as windowsnoob\EntAdmin on the Issuing CA server (IssuingCA), start the Certification Authority console by entering certsrv.msc, ensure that windowsnoob Issuing CA is expanded. Right-click on Certificate Templates, then select Manage. In the Certificate Templates that appear, select Workstation Authentication. Right click it, and select Properties, click on the Security tab, select Domain Computers and ensure that AutoEnroll is selected, click Apply. Step 3. Join the Windows 10 computer to the domain Logon to Windows 10 version 1803 computer (Win101803) as Administrator, and copy the JoinDomain.ps1 script below to a folder called C:\Scripts. Open the script in PowerShell ISE as Administrator, then run Set-ExecutionPolicy to unrestricted before running the JoinDomain.ps1 PowerShell script by clicking on the Green Arrow in Windows PowerShell ISE. JoinDomain.ps1 Note: The computer will reboot by itself after joining the windowsnoob.lab.local domain. Step 4. Check PKI Health with Enterprise PKI To use the Enterprise PKI console to check PKI health, on the IssuingCA server, ensure that you are logged on as windowsnoob\entadmin. Run PKIView.msc from an administrative command prompt. Right click Enterprise PKI and then click Manage AD Containers. On the NTAuthCertificates tab, verify the windows noob Issuing CA certificate appears with a status of OK as shown below: On the AIA Container tab, verify both the windows noob Root CA and the windows noob Issuing CA certificates are present with a status of OK. On the CDP Container tab, verify that the windows noob Issuing CA has both Delta CRL and Base CRL, and that the windows noob Root CA has a Base CRL present and with a status of OK. On the Certification Authorities Container, verify that the windows noob Root CA certificate is present and with a status of OK. and finally on the Enrollment Services Container tab, verify that the windows noob Issuing CA certificate is present with a status of OK. Step 5. Configure Certificate Distribution on the Issuing CA To publish a certificate for computers in the enterprise do as follows. Logon to the IssuingCA computer as windowsnoob\EntAdmin. In the Certification Authority console (certsrv.msc), ensure that windows noob Issuing CA is expanded. Right-click Certificate Templates, select New and select Certificate Template to Issue. On the Enable Certificate Templates dialog box, select Workstation Authentication and then click OK. Step 6. verify certificate autoenrollment on the Windows 10 client To verify that autoenrollment of certificates on the Windows 10 compute do as follows. Log on to win101803.windowsnoob.lab.local as windowsnoob\Administrator. (Ensure that you switch user to log on as windowsnoob\Administrator) Click Start, type mmc and then press ENTER. Click File, and then click Add/Remove Snap-in. Click Certificates, then click Add, Select Computer Account, and then click Finish. Click OK. Expand Personal and select Certificates, if you do not see Certificates, in an Administrative Command prompt issue the following command gpupdate /force then refresh the view in the Certificates MMC. You should now see a Certificates folder and a certificate listed. This certificate was issued using AutoEnrollment which was configured above. Step 7. Verify PKI health on the issued certificate While logged on to W101803.windowsnoob.local.local as windowsnoob\Administrator, In the certificates console tree, expand Personal, click Certificates. In the details pane, right click the W101803.windowsnoob.lab.local certificate, click All Tasks, and then click Export. the Welcome to the certificate export wizard appears, click Next. Click Next at the No do not export the private key screen On the Export File Format page, click Next. [DER encoded binary X.509 (.CER) is the default selection]. in the File to Export, call it C:\Windows10 at the completing the certificate export wizard screen click Finish. you should be notified of the success of the export. Open an administrative command prompt and run the following commands: cd\ then certutil -URL C:\Windows10.cer The URL retrieval tool should appear. In the URL Retrieval Tool, select the OCSP (from AIA) option and then click Retrieve. Confirm that it shows status as Verified. In the URL Retrieval Tool, select the CRLs (from CDP) option and then click Retrieve. Confirm that it shows status as Verified. In the URL Retrieval Tool, select the Certs (from AIA) option and then click Retrieve. Confirm that it shows status as Verified. Click Exit to close URL Retrieval Tool. From the administrative command prompt run following command to thoroughly verify the certificate chain retrieval and revocation status. certutil -verify -urlfetch C:\Windows10.cer you'll see a lot of output similar to the following PS C:\> certutil -verify -urlfetch C:\Windows10.cer Issuer: CN=windows noob Issuing CA DC=windowsnoob DC=lab DC=local Name Hash(sha1): b500ca9b33a216fcc44492f25bb6e6b8bd6a5a78 Name Hash(md5): b0c8a9c15f77c9e2b7af24718ab3f3ec Subject: EMPTY (DNS Name=W101803.windowsnoob.lab.local) Name Hash(sha1): f944dcd635f9801f7ac90a407fbc479964dec024 Name Hash(md5): a46c3b54f2c9871cd81daf7a932499c0 Cert Serial Number: 1e000000057a5838e2727d5162000000000005 dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ChainContext.dwRevocationFreshnessTime: 3 Weeks, 1 Hours, 35 Minutes, 37 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwRevocationFreshnessTime: 3 Weeks, 1 Hours, 35 Minutes, 37 Seconds CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=windows noob Issuing CA, DC=windowsnoob, DC=lab, DC=local NotBefore: 7/6/2018 4:04 AM NotAfter: 7/6/2019 4:04 AM Subject: Serial: 1e000000057a5838e2727d5162000000000005 SubjectAltName: DNS Name=W101803.windowsnoob.lab.local Template: Workstation Authentication Cert: 9eae120ea27c064e609df51cacda77e286a223d6 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- Verified "Certificate (0)" Time: 0 33daad0a6923fdbd02300d703264d13d70eedf42 [0.0] ldap:///CN=windows%20noob%20Issuing%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?cACertificate?base?objectClass=certificationAuthority Verified "Certificate (0)" Time: 0 33daad0a6923fdbd02300d703264d13d70eedf42 [1.0] http://pki.windows-noob.com/CertEnroll/IssuingCA.windowsnoob.lab.local_windows%20noob%20Issuing%20CA.crt ---------------- Certificate CDP ---------------- Verified "Base CRL (05)" Time: 0 7cf12cea65a271e322dcd148dafca9890381d68c [0.0] ldap:///CN=windows%20noob%20Issuing%20CA,CN=IssuingCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint Verified "Delta CRL (05)" Time: 0 b27c6e817abccb07e6d18c37c808013cc1377c1d [0.0.0] ldap:///CN=windows%20noob%20Issuing%20CA,CN=IssuingCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint Verified "Delta CRL (05)" Time: 0 b27c6e817abccb07e6d18c37c808013cc1377c1d [0.0.1] http://pki.windows-noob.com/CertEnroll/windows%20noob%20Issuing%20CA+.crl Verified "Base CRL (05)" Time: 0 7cf12cea65a271e322dcd148dafca9890381d68c [1.0] http://pki.windows-noob.com/CertEnroll/windows%20noob%20Issuing%20CA.crl Verified "Delta CRL (05)" Time: 0 b27c6e817abccb07e6d18c37c808013cc1377c1d [1.0.0] ldap:///CN=windows%20noob%20Issuing%20CA,CN=IssuingCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint Verified "Delta CRL (05)" Time: 0 b27c6e817abccb07e6d18c37c808013cc1377c1d [1.0.1] http://pki.windows-noob.com/CertEnroll/windows%20noob%20Issuing%20CA+.crl ---------------- Base CRL CDP ---------------- OK "Delta CRL (07)" Time: 0 b27c6e817abccb07e6d18c37c808013cc1377c1d [0.0] ldap:///CN=windows%20noob%20Issuing%20CA,CN=IssuingCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?deltaRevocationList?base?objectClass=cRLDistributionPoint OK "Delta CRL (07)" Time: 0 b27c6e817abccb07e6d18c37c808013cc1377c1d [1.0] http://pki.windows-noob.com/CertEnroll/windows%20noob%20Issuing%20CA+.crl ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 0 f7d32928b44de5b419a11bac19cc56fad7d4f9ee [0.0] http://webserver.windowsnoob.lab.local/ocsp -------------------------------- CRL 05: Issuer: CN=windows noob Issuing CA, DC=windowsnoob, DC=lab, DC=local ThisUpdate: 7/3/2018 7:02 AM NextUpdate: 7/10/2018 7:22 PM CRL: 7cf12cea65a271e322dcd148dafca9890381d68c Delta CRL 07: Issuer: CN=windows noob Issuing CA, DC=windowsnoob, DC=lab, DC=local ThisUpdate: 7/5/2018 7:02 AM NextUpdate: 7/6/2018 7:22 PM CRL: b27c6e817abccb07e6d18c37c808013cc1377c1d Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=windows noob Root CA NotBefore: 6/19/2018 4:34 AM NotAfter: 6/19/2028 4:44 AM Subject: CN=windows noob Issuing CA, DC=windowsnoob, DC=lab, DC=local Serial: 5600000002ff2362e624faf00a000000000002 Template: SubCA Cert: 33daad0a6923fdbd02300d703264d13d70eedf42 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- Verified "Certificate (0)" Time: 0 1c2e0479a69623ffddcec692d01af64996b2b6e9 [0.0] ldap:///CN=windows%20noob%20Root%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?cACertificate?base?objectClass=certificationAuthority Verified "Certificate (0)" Time: 0 1c2e0479a69623ffddcec692d01af64996b2b6e9 [1.0] http://pki.windows-noob.com/CertEnroll/ROOTCA_windows%20noob%20Root%20CA.crt ---------------- Certificate CDP ---------------- Verified "Base CRL (02)" Time: 0 22cafd2ae550e12401696bac4a424652050c55a2 [0.0] ldap:///CN=windows%20noob%20Root%20CA,CN=ROOTCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=windowsnoob,DC=lab,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint Verified "Base CRL (02)" Time: 0 22cafd2ae550e12401696bac4a424652050c55a2 [1.0] http://pki.windows-noob.com/CertEnroll/windows%20noob%20Root%20CA.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 (null) ---------------- Certificate OCSP ---------------- No URLs "None" Time: 0 (null) -------------------------------- CRL 02: Issuer: CN=windows noob Root CA ThisUpdate: 6/15/2018 3:12 AM NextUpdate: 6/14/2019 3:32 PM CRL: 22cafd2ae550e12401696bac4a424652050c55a2 CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=windows noob Root CA NotBefore: 6/14/2018 11:03 AM NotAfter: 6/14/2038 11:13 AM Subject: CN=windows noob Root CA Serial: 3d0d623b5abd19b34640212c87d45269 Cert: 1c2e0479a69623ffddcec692d01af64996b2b6e9 Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 (null) ---------------- Certificate CDP ---------------- No URLs "None" Time: 0 (null) ---------------- Certificate OCSP ---------------- No URLs "None" Time: 0 (null) -------------------------------- Exclude leaf cert: Chain: d5f425d64a9d41434507a599da1260fdced44873 Full chain: Chain: 0c69840fda437706dd390c3d120ab496038c2564 ------------------------------------ Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.5.5.7.3.2 Client Authentication Leaf certificate revocation check passed CertUtil: -verify command completed successfully. PS C:\> Review the output and make sure all the chain retrieval and revocation status are successfully verified. Job done ! That's it for this mini-series about setting up PKI in a lab, thanks for joining me, I hope you completed everything successfully and have a better understanding of how PKI works and how to set it up in a lab. Next steps If you'd like to see how SCCM works with HTTPS, see below:- How can I configure System Center Configuration Manager in HTTPS mode (PKI) - Part 1 How can I configure System Center Configuration Manager in HTTPS mode (PKI) - Part 2 cheers niall.

Introduction This is part 2 in a series of guides about cloud attach in Microsoft Endpoint Manager, with the aim of getting you up and running with all things cloud attach. This part will focus on preparing your environment for a Cloud Management Gateway (CMG). This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. Paul is 4 times Enterprise Mobility MVP based in the UK and Niall is 10 times Enterprise Mobility MVP based in Sweden. In part 1 we configured Azure AD connect to sync accounts from the on premise infrastructure to the cloud. In this part we'll prepare your environment for a Cloud Management Gateway. A Cloud Management Gateway gives you a whole bunch of new abilities for managing, imaging computers, escrowing BitLocker keys and delivering software, updates and policy to remote based internet enabled clients. Cloud attach - Endpoint Managers silver lining - part 1 Configuring Azure AD connect Cloud attach - Endpoint Managers silver lining - part 2 Prepare for a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 3 Creating a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 4 Enabling co-management Cloud attach - Endpoint Managers silver lining - part 5 Enabling compliance policies workload Cloud attach - Endpoint Managers silver lining - part 6 Enabling conditional access Cloud attach - Endpoint Managers silver lining - part 7 Co-managing Azure AD devices Cloud attach - Endpoint Managers silver lining - part 8 Enabling tenant attach Prerequisites Azure: Intune Tenant already created Azure Subscription (free trial) Licenses applied, you can grab a free trial of Enterprise Mobility plus Security which includes Intune and Azure AD Premium P2 here (free trial). Intune is configured to auto-enroll devices (guide) Configuration Manager: PKI enabled (guide) Configuration Manager current branch, version 1810 or later. The MDM authority must be set to Intune Permissions: The following permissions are required to be able to set up the Cloud Management Gateway: An account that is a global administrator for Azure Active Directory An account that is a domain admin on your on-premises infrastructure An account that is a full administrator for all scopes in Configuration Manager Step 1. Add Classic Compute and Storage In order to setup the Cloud Management Gateway, you will need to register a couple of the resource providers in Azure (Microsoft.ClassicCompute & Microsoft.Storage). These resource providers may already be registered in your tenant, but you should check to ensure that they are and if not, act accordingly. Launch the Azure port at https://portal.azure.com, go to Subscriptions, select your subscription, and choose Resource Providers in the Settings section. Search for Microsoft.Classic.Compute, select it and if it is listed with a status of NotRegistered then click Register. It will register the provider. After a few moments the provider should appear as registered. Repeat the above process for Microsoft.Storage so that both providers are listed as Registered. Step 2. Check for a unique name of your CMG instance Verify in Azure that you have a unique name for your CMG, this is a unique name using Microsoft’s cloudapp.net namespace. You cannot reserve this name, only check for its availability. To do this, search for Cloud Service in the Azure portal and go to the Cloud service (classic) page. Click Add link. In the DNS name field, search for the name you want to use. Note that this name will not be visible to anyone on the outside world, so can be any available name you want. For our DNS name, we searched for CloudAttachCMG and as a result you want to see green ticks on both Match Found and DNS name. Both conditions must be met, if not you will get a red cross and you will need to search for another name. Note the .cloudapp.net entry next to the DNS name field, the full name associated with the cloud management gateway VMs will be DNSName.cloudapp.net – so our CMG VM’s will be cloudattachcmg.cloudapp.net. Do not save anything here, as mentioned you are just checking for availability. Step 3. Create a CNAME record You are going to request an external PKI certificate to secure communication to the CMG, but prior to that you need to reate a CNAME record at your external DNS provider. We cannot run through that process, as each provider is different, but you need to create a CNAME record to map to your chosen DNSName.cloudapp.net address. We have mapped cloudattachcmg to cloudattachcmg.cloudapp.net. A couple of things to note here: If you have an existing TXT record in your DNS you may need to delete this for the new CNAME to work, we saw issues in two tenants that would not properly create the CNAME record until we removed the previously created TXT record. You will need to add in a CNAME to your internal DNS servers if your internal DNS namespace is identical to your external namespace. Below you can see the created CNAME record in the DNS provider of the custom domain name we added in part 1. Tip: You can use dnschecker.org to see that your CNAME has propagated successfully. Step 4. Create an External PKI cert for the external address Note: you can run this tool on any computer, it's only needed to generate the files needed in the remaining parts. We downloaded a digital certificate utility from DigiCert for creating a Certificate Signing Request (CSR) but you can do this process on an IIS server see here. A CSR is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. Source Using the tool above (from Digicert, our external SSL certificate provider, there are many to choose from), click on Generate to create the CSR. After generating the CSR, save it to a file. Next, go to your certificate provider and request a new SSL certificate based on the CSR you just created. The screenshot below is from our certificate provider, DigiCert, your provider will most likely look different. When creating the SSL certificate, you'll probably have to prove control over the domain, we chose the option to use a DNS TXT Record (recommended). Be sure to enter the cloudattachcmg prefix (yours will be different obviously) into the record for the TXT DNS validation otherwise it might have problems finding the TXT record. After creating the TXT record you can verify it with dnschecker, as shown here, this is helpful in troubleshooting whether your DNS record (TXT, CNAME etc...) is valid or not. After verifying that you own the domain, you'll be able to download the created CRT (certificate). Next, import the downloaded CRT back into the Digicert tool. Click Finish to complete the CRT import process. and you should see a notification about the success of the import. Step 5. Export the pfx Select the Imported certificate. Click on Export Certificate choose the option to export pfx You'll be prompted for a password and you'll be informed of the successful export. Step 6. Configure Azure services To configure Azure services from within the Configuration Manager console, use the Configure Azure Services wizard to create two Azure Active Directory (Azure AD) apps. Server app – a Web app in Azure AD Client app – a Native Client app in Azure AD On the primary site server, open the Configuration Manager console and go to Administration > Cloud Services > Azure Services, and select Configure Azure Services. On the Configure Azure Service page, specify a friendly name for the cloud management service you're configuring, for example Cloud Management Service. Then select Cloud Management from the options and then select Next. On the App Properties page, for Web app, select Browse to open the Create Server Application dialog, configure the following fields: Application Name: Cloud Management Server App Home page URL: https://ConfigMgrService App ID URI: https://ConfigMgrService Secret key validity period: 2 years Next, select Sign in, and specify an Azure AD Global Administrator account. These credentials aren't saved by Configuration Manager. This persona doesn't require permissions in Configuration Manager and doesn't need to be the same account that runs the Azure Services Wizard. After you sign in, the results display. Select OK to close the Create Server Application dialog and return to the App Properties page. Next, select Browse to the right of the Native Client App section, the Create Client Application dialog, and then configure the following fields: Application Name: Cloud Management Client App And sign in. Click OK and click OK again, both apps will now be listed. On the Configure Discovery Settings page, check the box for Enable Azure Active Directory User Discovery, select Next, and then complete configuration of the Discovery dialogs for your environment. Click through to the end of that wizard and close the wizard. Your cloud management service that you just configured will be listed in the console. Step 7. Set API permissions on the server and client apps Open a browser and sign in to the Azure portal. Select All services > Azure Active Directory > App registrations, then click All Applications. Select the Cloud Management Server App you created. Go to API permissions or select View API permissions Click the Grant admin consent link Click Yes when prompted. You'll be informed of the success. Repeat this process for the Cloud Management Client App. Pay attention to the fact that it doesn't have the same permissions listed before you grant consent. and here is the same app after the api permissions are applied. That's it for this part ! Please join us in part 3 where we'll configure the Cloud Management Gateway. Useful links Plan for Cloud Management Gateway - https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#hierarchy-design Certificates needed for CMG - https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/certificates-for-cloud-management-gateway Cloud attach and Microsoft Endpoint Manager - https://techcommunity.microsoft.com/t5/business-continuity-and-disaster/cloud-attach-and-microsoft-endpoint-manager/m-p/1498577 Download Azure AD Connect - Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center Azure AD connect prerequisites - https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites How to setup Azure AD Connect using express settings - https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-express

Introduction Microsoft released Windows Intune back in March 2011, this was their launch pad to get users into the cloud. This later evolved into Microsoft Intune and is now known as Microsoft Endpoint Manager. This cloud journey encompassed several new technologies and associated buzz words summarized below. Hybrid MDM – Depreciated, this was the first combination of ConfigMgr and Intune Co-management – The ability to manage devices via ConfigMgr and Intune Co-existence – Using a 3rd party MDM solution together with ConfigMgr Cloud Attach – Attaching cloud components to a ConfigMgr environment Tenant attach – Attaching ConfigMgr managed devices including servers to the cloud This part is the first part in a series of guides about cloud attach in Microsoft Endpoint Manager and the guides are co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. Paul is 4 times Enterprise Mobility MVP based in the UK and Niall is 10 times Enterprise Mobility MVP based in Sweden. If you use Twitter and want to see content when we release it then please do follow us: @ncbrady @SCCMentor Why are we writing this? Both Paul and I have worked on multiple cloud-based lab scenarios together over the course of the last year keeping ourselves educated and involved during lock down. We focused on expanding our knowledge about these exciting new technologies that come with the enabling of cloud attach features. That includes advanced cloud capabilities offered via a Cloud Management Gateway (CMG), co-management and additional capabilities available via Tenant attach. This area of modern management is rapidly evolving, now more than ever as workers find themselves working remotely during COVID-19, therefore it’s important to keep up with what’s new and what is changing. Cloud attach - Endpoint Managers silver lining - part 1 Configuring Azure AD connect Cloud attach - Endpoint Managers silver lining - part 2 Prepare for a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 3 Creating a Cloud Management Gateway Cloud attach - Endpoint Managers silver lining - part 4 Enabling co-management Cloud attach - Endpoint Managers silver lining - part 5 Enabling compliance policies workload Cloud attach - Endpoint Managers silver lining - part 6 Enabling conditional access Cloud attach - Endpoint Managers silver lining - part 7 Co-managing Azure AD devices Cloud attach - Endpoint Managers silver lining - part 8 Enabling tenant attach This multi part blog will focus on helping you get your organization cloud attached, and we will start by assuming that your environment has a few key aspects already setup: PKI enabled (guide) Intune Tenant created Azure Subscription (free trial) Licenses applied, you can grab a free trial of Enterprise Mobility plus Security which includes Intune and Azure AD Premium P2 here (free trial). In this part we will show you how to do the following: 1. Add a custom domain name to Azure 2. Set up a User Principal Name (UPN) for your on-premises Active Directory 3. Set up hybrid Azure AD Join using Azure AD Connect 4. Configure hybrid Azure AD join using Azure AD Connect So, let’s get started. Step 1. Add a Custom Domain Name to Azure Login to https://portal.azure.com select Azure Active Directory to add a custom domain name in Azure AD Directory. Select custom domain names in the left pane and then click the + Add custom domain link in the top ribbon. When presented with the Custom domain name window, enter the name of the domain you own and click the Add domain button. After adding the domain name, you’ll be shown a screen similar to the one below, you can choose to add a TXT or MX record on your DNS provider. In the example below we chose the TXT option. Enter the provided TXT record at your domain name provider. Below is example of the TXT record we entered at out providers DNS management portal. We’ve set the TTL to a low value to get this propagated quickly so that we can verify the domain. Tip: You can use a website such as dnschecker.org to see if the TXT record has propagated and can be queried, when this has happened go back to the Azure portal and click the Verify button to verify the domain. Once the domain is successfully verified, it will report as so in the Custom domain names blade. After the custom domain name is added, you can make it the Primary domain name. To do that do as follows. Select the custom domain name which you have verified above, and click on Make Primary. After doing that your custom domain name will be the new Primary domain name. Step 2. Set up a User Principal Name (UPN) for your on-premises Active Directory With the custom domain name added and set to primary we are going to add an alternative user principal name suffix into the on-premises Active Directory. This will match the domain name we have verified, so our example is azurenoob.com. This is fairly simple to set up, but once configured, we need to set this as the default for our users and we can use a PowerShell script to achieve this. Let us start off by setting the UPN, you will need to be a Domain Admin or Enterprise Admin to achieve this. Open Active Directory Domains and Trusts. Right click on Active Directory Domains and Trusts, and select Properties. Type in your new alternative name suffix into the Alternative UPN suffixes box, and click Add. Click OK. Below you can see we've added azurenoob.com. Now we need to set the alternative UPN as the default UPN for all our users. Thanks to the community we can use a PowerShell script which is already out there to achieve this, and we used a script from martinsblog.dk. You can be granular with this script, so that you only add in a specific OU for your users, or you could run it at the top level of the domain. Below is the properties of an user with the new UPN applied. Step 3. Set up hybrid Azure AD Join using Azure AD Connect You can use Azure AD Connect to integrate on-premises and online directories. It can synchronize computer, user and group objects and assist with single sign-on in both directories as well as password sync. When using the Azure AD Connect it’s recommended to download the latest release. You can obtain this from Microsoft Download Center. A minimum of version 1.1.819.0 is needed, but this is an old version, you would be better off downloading the latest and using the newer features available with that release. Download Azure AD Connect here. After downloading and installing the tool, launch it and Agree to the terms and conditions before clicking Continue. We have the choice of running an express installation or customizing the install. Microsoft recommends using the customize option if you have multiple forests or if you want to configure optional features, otherwise you can continue with the Use express settings option. In the steps below we run through the options you'll see when choosing Use Express Settings. Next, enter the Global Admin login details for your Azure Ad environment. Click Next and then enter the Enterprise Admin credentials for the on-prem Active Directory Domain Services. Note: The Azure AD sign-in configuration page only shows if you did not complete verify your domains in the prerequisites. If you see this page, then review every domain marked Not Added and Not Verified. Make sure those domains you use have been verified in Azure AD. Click the Refresh symbol when you have verified your domains. If you have domains marked as Not Added then see the next step. The azurenoob.com domain is Verified as we verified this domain in Azure AD. This also means we will be able to sign in with the same credentials in our on-premises Active Directory as we also added in the UPN. Select the checkbox to Continue without matching all UPN suffixes to verified domains if one of your UPN suffix values is not added, for example the windowsnoob.lab.local address is in the state Not Added. You will only have this checkbox available if you have a Not Added entry and you must check the box in order to continue. Click Install We have enabled the checkbox for Start the synchronization process when configuration completes as we want the synchronization process to start once we have completed the wizard. If you do not enable this, the sync will be configured but won’t run until you re-run the Azure AD Connect wizard. Click Install. After clicking Install the wizard will start configuring. And after a few minutes it’s complete. You can close the wizard by clicking on Exit. Step 4. Configure hybrid Azure AD join using Azure AD Connect With the express settings configured, we now need to configured Azure AD Connect for hybrid Azure AD join of our on-premises devices. Launch the Azure AD Connect wizard and click Configure to continue. On the Additional tasks page, select Configure device options, and then select Next. Select the option to Configure Device Options. On the next screenshot note that we are interested in Hybrid Azure Ad join and that Hybrid Azure AD join enables devices in your Active Directory forest to register with Azure AD for access management. Computers in your organization will automatically discover Azure AD using a service connection point (SCP) object that is created in your Active Directory forest. On the Overview page select Next. On the Connect to Azure ad page enter the credentials of your Global Admin. On the Device options screen, select Configure Hybrid Azure AD join to synchronize our on-premise devices and to configure them for Azure Ad join. The Service Connection Point (SCP) needs to be configured for each forest where you want to enable Hybrid Azure AD join. We only have the one forest. Click the Add button. Select Windows 10 or later domain-joined devices and then click Next. Select the check box beside your on premise domain and then click Add. Enter your Enterprise Admin Credentials when prompted. Click Next. And at the Ready to configure screen click Next. At the Configuration complete, click Exit. That's it for this part, join us in Part 2 where we will prepare your environment for a Cloud Management Gateway. Useful links Cloud attach and Microsoft Endpoint Manager - https://techcommunity.microsoft.com/t5/business-continuity-and-disaster/cloud-attach-and-microsoft-endpoint-manager/m-p/1498577 Download Azure AD Connect - Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center Azure AD connect prerequisites - https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites How to setup Azure AD Connect using express settings - https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-express

awesome to hear it ! spread the word 🙂

Yeh whilst an option i just decided to go the destroy way so we have packages to remove all the unneeded software and as mentioned above modified the office install to attempt to remove office whilst also supressing error codes. PSAPPDEPLOY code is Execute-Process -Path "$dirFiles\setup.exe" -Parameters "/CONFIGURE remove.xml" -ContinueOnError $true -IgnoreExitCodes '*' and remove xml is below - not sure i need the remove all true whilst also calling out products but the reality sometimes doesnt match the documentation with Microsoft <?xml version="1.0"?> -<Configuration> <Display AcceptEULA="True" Level="None"/> <Property Value="TRUE" Name="FORCEAPPSHUTDOWN"/> -<Remove All="TRUE"> -<Product ID="O365ProPlusRetail"> <Language ID="en-us"/> </Product> -<Product ID="VisioProRetail"> <Language ID="en-us"/> </Product> -<Product ID="ProjectProRetail"> <Language ID="en-us"/> </Product> </Remove> </Configuration>

Hi, I reviewed the Task Sequence (for which thanks a million!) and I believe the reason for 'error 87:parameter is not correct' in two of the steps you disabled for the time being is the wrong dism parameter: DISM.exe /image:%OSDisk%\ /Set-UILanguage:%OSDUILanguage% that should be-> DISM.exe /image:%OSDisk%\ /Set-UILang:%OSDUILanguage% Similarly Set-UILanguageFallback should be changed to Set-UILangFallback. I did not have enough time to test that one myself yet but according to DISM documentation Set-UILang is the parameter name that exists.

If anyone gets an access denied error at the last step (certutil -crl), then please reboot your Issuing CA server once and then issue the command again. I had this issue and apparently several other users had this too per various forums.

You can import the module by exploiting the environment variables to keep it less static. Import-Module -Name "$(split-path $Env:SMS_ADMIN_UI_PATH)\ConfigurationManager.psd1"

This list of guides (think of it as a living index) will be updated by me whenever I write a new guide for the new versions of Microsoft Endpoint Manager (Configuration Manager) or Endpoint Manager (Intune). These guides are broken down into different sections: Endpoint Manager - Intune Endpoint Manager - Current Branch Endpoint Manager - Technical Preview Setting up PKI The Current Branch release is meant for your production deployments and the Technical Preview releases are for testing new upcoming features in the product, and are aimed at Lab use only. The PKI guides are added in case you want to experiment with any roles requiring certificates. Endpoint Manager - Intune Adding devices or users to an Azure AD group after Windows Autopilot is complete but only when the device is marked as Compliant Gathering logs and sending an email when resetting Windows Autopilot - part 1 Gathering logs and sending an email when you need to reset Windows Autopilot - part 2 Gathering logs and sending an email when you need to reset Windows Autopilot - part 3 Adding devices to an Azure AD group after Windows Autopilot is complete - part 1 Adding devices to an Azure AD group after Windows Autopilot is complete - part 2 Displaying a welcome page after Windows Autopilot completes Office 365 issues after Windows Autopilot Removing company data from Endpoint Manager enrolled phones Configuring the Registered Owner and Organization in Windows Autopilot delivered PCs Troubleshooting app deployment in Windows Autopilot How can I create dynamic groups for different HoloLens devices in Microsoft Intune Android device management with Microsoft Intune – Part 1. Partnerships Android device management with Microsoft Intune – Part 2. Deployment Scenarios Android device management with Microsoft Intune – Part 3. Dedicated device management Android device management with Microsoft Intune – Part 4. Coming soon and what’s new How Microsoft uses Intune internally to manage Windows devices Learn how to leverage Intune support for Microsoft Graph and PowerShell to enable powerful automation and IT security- my notes Managing devices with Microsoft Intune: What’s new and what’s next – my notes (Part 1 – new features) Managing devices with Microsoft Intune: What’s new and what’s next – my notes (Part 2 – iOS) Managing devices with Microsoft Intune: What’s new and what’s next – my notes (Part 3 – Android) Managing devices with Microsoft Intune: What’s new and what’s next – my notes (Part 4 – macOS) Managing devices with Microsoft Intune: What’s new and what’s next – my notes (Part 5 – Windows) How can I deploy custom favorites in Microsoft Edge to Windows 10 devices using Microsoft Intune How can I send notification messages using PowerShell in Microsoft Intune Configuring BitLocker in Intune - Part 3. Testing the scripts Configuring BitLocker in Intune - Part 2. Automating Encryption Configuring BitLocker in Intune - Part 1. Configuring BitLocker Troubleshooting “Something went wrong error 801c0003” during enrollment via Windows AutoPilot and Microsoft Intune How can I use Windows AutoPilot with a Proxy ? How can I customize the start screen in Windows 10 using Intune How can I enable MDM auto-enrollment in Azure How can I create a dynamic group containing all Windows 10 version 1709 in Intune in Azure ? How can I integrate Microsoft Store for Business with Intune in Azure Getting started with Microsoft Graph and using PowerShell to automate things in Intune Using Intune to enable WIP to protect Enterprise data on Windows 10 devices (MAM-WE) What is Windows Information Protection and how can I use it to protect Enterprise data on Windows 10 devices using Intune Intune Preview in Azure get’s a new look and Software Updates for Windows 10 ! How can I check the status of my Intune service ? How can I determine how long a blade loads in Intune Preview in Azure ? How can I unlock Windows Holographic for Business features in Intune Preview? How can I find out version info about Intune Preview in Azure ? Endpoint Manager (Current Branch) Installation - How can I install System Center Configuration Manager (Current Branch) Configuring Discovery - How can I configure discovery for System Center Configuration Manager (Current Branch) Configuring Boundaries - How can I configure boundaries in System Center Configuration Manager (Current Branch) Using Updates and Servicing in Offline mode - How can I use Updates and Servicing in Offline mode in System Center Configuration Manager (Current Branch) Using Updates and Servicing in Online mode - How can I use Updates and Servicing in Online mode in System Center Configuration Manager (Current Branch) Setting up the Software Update Point - How can I setup Software Updates in System Center Configuration Manager (Current Branch) Installing the Client agent - How can I configure client settings and install the ConfigMgr client agent in System Center Configuration Manager Current Branch Upgrading to System Center Configuration Manager (Current Branch) version 1602 from System Center Configuration Manager (Current Branch) version 1511 How can I use the Upgrade Task Sequence in System Center Configuration Manager (Current Branch) ? How can I use servicing plans in System Center Configuration Manager (Current Branch) to upgrade Windows 10 devices ? How can I deploy Windows 10 with MDT 2013 Update 2 integrated with System Center Configuration Manager (Current Branch) Setting up PKI Part 1 - Introduction and server setup Part 2 - Install and do initial configuration on the Standalone Offline Root CA Part 3 - Prepare the HTTP Web server for CDP and AIA Publication Part 4 - Post configuration on the Standalone Offline Root CA Part 5 - Installing the Enterprise Issuing CA Part 6 - Perform post installation tasks on the Issuing CA Part 7 - Install and configure the OCSP Responder role service Part 8 - Configure AutoEnroll and Verify PKI health cheers niall

Updating the boot media and redistributing the content to the DP after it was configured properly for PXE did the trick for me. Thanks for the tip.

On the SCCM Side, You can follow this guide to extend the schema For the rest, we have used SCCM and VMware clusters alot and find very few issues with them once you get teething issues out of the way, this includes things like vlan's/trunking etc. it can be a pain especially if your using the newer Nexus V1000 vSwitch for vSphere.. basic things i assume you'll sort out when thinking logically about it.... We separate our SCCM Central Servers from DP's as this is going to cause you alot of traffic, for our first deployment we have a couple of DP's sitting beside our SCCM Provider to handle this workload. its choice and licensing though... so go with what you feel your environment can handle... 170 WS's id say is achievable... we run between 200-500 a session during a deployment.... but just be aware its not a simple set and forget which is where alot of deployments come undone... you need to set them off and hang around for an hour or so... especially if multi casting as in our experience it seem to be still a tad on the flakey side... nothing worse than 80users showing up Monday morning without a PC to use.... I would suggest you stick with smaller groups over a few nights, ESPECIALLY if migrating from XP.... Is there any reason you couldn't script your pc naming? There's some more to go with all this but i suggest you pick a pilot target of 10-20 desktops and push it out on a Wednesday night so you have a couple of days to iron out the kinks.... and there will be kinks. For your driver issue, i'd be using SCCM if possible, and be building Driver Packs per http://www.windows-noob.com/forums/index.php?/topic/2428-how-to-create-a-driver-package/ .... read the whole post, checkout how to query WMI and install drivers that way if you have more concerns. Im not a huge fan of using just MDT and WDS to deploy, to much extra scripting required to get your basics setup..... this is just my experience and 2cents