anyweb

welcome to the forums ! we are happy to help

it's not broken, you just need to be logged in as a member to download files from windows-noob.com now you are so please try again.

ah is there a child task sequence involved ? Run Task Sequence step is disabled. Not including child task sequence with package ID 'PRI004CA' into the sequence.

create a virtual machine machine the same setup as your primary, install SQL, and restore the db on that vm, that would be how i'd do it...

you need the actual sql server 2017 ISO (the cd) in drive d:\ or whatever drive you are attaching it to... that is the installation media

what does the smsts.log tell you ?

how did you install sql ? that's where the sql accounts) are defined...

no problem, I've reminded them that people are seeing it so hopefully a bug fix will come soon

it's a bug, the microsoft product group are aware of it, it doesn't happen for everyone, just some people cheers niall

so again, what is causing it to be critical, what do the status messages say ?

I don't understand what you are saying...

and what is it complaining about ?

warnings are just that, warnings. They are not errors. It looks ok to me...if you look at the actual status of the individual components that have warnings, how do they look ?

ok back to the basics, are you upgrading the site using the inbuilt upgrade ability, or what are you trying to do exactly

restart the server and see is your problem solved

you said and i quote... you need to configure your antivirus exclusions in THAT product if it's the product that is doing antivirus on your configmgr server... is it ?

...

here you go https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/recommended-antivirus-exclusions

can you uninstall the antivirus software, reboot the server and try again, or if you cannot uninstall it, create exclusions for SMS related files and folders

what version of configmgr is it ? and do you use 3rd party antivirus ?

also, have you seen this post from Eswar, he's not using PKI either but it's working for him http://eskonr.com/2021/01/certificate-error-while-deploying-an-os-over-cmg-using-bootable-media/

how are you deploying the feature update ? what does the windowsupdate.log tell you ?

so I got this back from the very knowledgeable Jason in the PG "The problem here appears to be that the cert on the CMG is issued by an internal CA and thus not trusted by the WinPE environment. Using a cert from a public PKI is the only way I know of to get past this (or using a pre-start script to add the issuing PKI as trusted before the TS engine launches)."

I haven't tested it in non-pki environments and a quick look at the documentation only states this " For version 2010 early update ring, if you use a PKI-based certificate for the boot media, configure it for SHA256 with the Microsoft Enhanced RSA and AES provider. For later releases, including globally available version 2010, this certificate configuration is recommended but not required. The certificate can be a v3 (CNG) certificate. " In other words, it doesn't call out non-PKI environments or token based auth in this scenario, i'll ping the product group and ask if it's actually supported cheers niall

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. Below you can find all parts in this series. 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 <- you are here 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 Cloud attach - Endpoint Managers silver lining - part 9 Renewing expiring certificates Cloud attach - Endpoint Managers silver lining - part 10 Using apps with 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