anyweb

from the log there are several reports of SQL access issues, double check your permissions before trying again. *** [42000][4060][Microsoft] [SQL Server]Cannot open database "CM_MDC" requested by the login. The login failed.

please attach your cmupdate.log....

have you made sure it's got the latest bios ?

can you explain what you mean by " due to home lab situation. "

I assume you upgraded the CAS first and then the PRI, are there any errors at all in the cmupdate.log that you think may be important on either site ?

if i have the energy and time this week (doubt it) I might try and test this for you...

nope haven't had time yet, what if anything do the logs tell you ? what adk are you using ?

good troubleshooting !

hi are you seeing this after completing my 8 part lab ?, I've booted mine up, and verified on the IssuingCA as EntAdmin with pkiview that everything looks good, and it still does after leaving it running for a day, i'd suggest you start at the beginning again and work your way through it, it's a good exercise anyway, take snapshots after completing each Part, so that you can always revert if there's an issue later.

4gb should be ok but i would put a pause before the install offline language step and after to analyze logs to see what's happening.. here's one way - also try and move to a supported scenario, as it's impossible to say if this is because you are running unsupported right now...without me too trying it, and i don't have time, sorry

hmm you are using adk 1803 to deploy windows 10 1607 images ? i don't think that's supported, but aside from that, how much ram is in these computers and have you also updated the mdt integration to a newer release ? are you really still deploying windows 10 1607 it's eol in November

did you try rebooting the cas & pri to see if it makes any difference ?

take a look at this old post to give you some ideas of where you are going wrong

yes you can do that, but if you are installing more than one language then you must include all the language packs you intend to install together

Microsoft has introduced support for the Web Authentication specification in Microsoft Edge, enabling better, more secure user experiences and a passwordless experience on the web. With Web Authentication, Microsoft Edge users can sign in with their face, fingerprint, PIN, or portable FIDO2 devices, leveraging strong public-key credentials instead of passwords. A web without passwords Staying secure on the web is more important than ever. We trust web sites to process credit card numbers, save addresses and personal information, and even to handle sensitive records like medical information. All this data is protected by an ancient security model—the password. But passwords are difficult to remember, and are fundamentally insecure—often re-used, and vulnerable to phishing and cracking. For these reasons, Microsoft has been leading the charge towards a world without passwords, with innovations like Windows Hello biometrics and pioneering work with the FIDO Alliance to create an open standard for passwordless authentication – Web Authentication. We started this journey in 2016, when we shipped the industry’s first preview implementation of the Web Authentication API in Microsoft Edge. Since then, we have been updating our implementation to as we worked with other vendors and the FIDO alliance to develop the standard. In March, the FIDO Alliance announced that the Web Authentication APIs have reached Candidate Recommendation (CR) status in the W3C, a major milestone for the maturity and interoperability of the specification. Authenticators in Microsoft Edge Beginning with build 17723, Microsoft Edge supports the CR version of Web Authentication. Our implementation provides the most complete support for Web Authentication to date, with support for a wider variety of authenticators than other browsers. Windows Hello allows users to authenticate without a password on any Windows 10 device, using biometrics—face and fingerprint recognition—or a PIN number to sign in to web sites. With Windows Hello face recognition, users can log in to sites that support Web Authentication in seconds, with just a glance. Users can also use external FIDO2 security keys to authenticate with a removable device and your biometrics or PIN. For websites that are not ready to move to a completely passwordless model, backwards compatibility with FIDO U2F devices can provide a strong second factor in addition to a password. via > https://blogs.windows.com/msedgedev/2018/07/30/introducing-web-authentication-microsoft-edge

Introduction Those of you who regularly read my guides know that I favor using Hyper-V over VMware for virtual machine work. I like the seamless integration with Windows and the fact that it comes built in to Windows 10. This blog post is about backing up your Hyper-V virtual machines on Windows Server 2016 to Microsoft Azure Cloud Storage using Altaro VM backup software, their software does show the process in 3 steps, but in reality, you need to do more things which I've detailed below. Step 1. Configure Azure Cloud Storage If you've already done this, please skip to step 2 otherwise sign in (or sign up) to the Azure Portal account using https://portal.azure.com. In the Azure Portal, click on the + sign to Create a resource (1) select Storage (2) then select Storage Account (3) Give the storage account a name and select General Purpose v1 as the Account kind (as General Purpose v2 would cost more). For Replication, select Locally redundant storage (LRS). For Performance, leave the default setting of Standard. Click on Create when done. Note: Ensure you select General Purpose v1 as the Account kind as it will result in the lowest cost. This is due to: "workloads with high churn or high read rates may benefit from this account type." Reference: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-account-options Step 2. Download & install Altaro VM Backup software Next you need to go to Altaro's website here where you can download the 30-day free trial of Altaro VM Backup. If you’re opting for the free edition, you will still automatically get a 30-day trial of the Unlimited Plus version, which includes the backup to Azure feature. Note: You'll need Windows Server operating system such as Windows Server 2016 to host Hyper-V for this to work, Altaro VM Backup does not support Windows 10 (sadly). To see a list of supported operating systems click on this link. Once you've downloaded the trial, install it. It's a very simple installation wizard and once done you can launch the Altaro VM Backup console. Step 3. Configure an on premise backup location Now that you've installed Altaro VM Backup, you can start configuring it. In the console ensure that This machine is selected then click on Connect. Below is what it looks like when you haven't yet configured anything. Note: You are required to configure an on premise backup location prior to backing up over the WAN to Azure Cloud Storage. Select Backup Locations in the left pane, and then click on one of the two available on premise locations, in my example I selected Physical drive. click Next and select the destination drive (and previously created folder) where you want to store the backups. click on Finish. Step 4. Select which virtual machines to backup Now that you've configured a backup location, select one or more virtual machines and drag and drop them to the on premise backup location. Each selected virtual machine that you drag and drop, will then appear under that backup location. Click on Save Changes in the lower right corner of the Altaro VM Backup console once done. Step 5. Configure Offsite Location In the Altaro VM Backup console Click on Add Offsite Location (top right) and from the Offsite options that appear, select Azure (Cloud Backup to an Azure Storage Account) and then click Next. Note: There is a link to How to set up Offsite Copies to an Azure Cloud Storage Account, if you need help configuring that click on it otherwise see Step 2 above. Next, you'll need to find the Azure Storage Connection string associated with your Azure Cloud Storage. To do that, in the Azure Portal, select Storage Accounts, select the storage you previously created, and then select Access Keys. The Connection String will be listed, select it and copy it. Paste that Connection String into the empty field in Altaro VM Backup Click Finish. You should see Connection Established Successfully in the top right corner. next, drag and drop the virtual machine(s) that you want to backup to the cloud and finally, click on Save Changes in the lower right corner. You'll be prompted to Set an Encryption Key. This key is basically a text based password that you will use to protect your backups, so make sure it's something secure and that all people that need to access the backups are aware of. click on the green Save button. Once done, you'll notice that Save Changes is RED in colour, this means you cannot click on it, I found it a bit confusing but as long as you've done the steps I've outlined you'll be ok. Step 6. Take a (on premise) backup Now that you've configured an Azure Storage Account as an offsite backup location, you are ready to take a backup. However, you must first take a primary backup (on premise) before being able to backup to the cloud. To do that, click on Take Backup in the left pane. Select one or more virtual machines that you want to backup before clicking on the even redder Take Backup button. you can then click on the Storage symbol (shown here with a red arrow) to get live information about the backup in progress. Once the backup is done, you can verify it's progress in the Take Backup window. Step 7. Take an offsite backup At this point, everything is in place for your first backup to Azure Cloud Storage. So go ahead and click on Take Offsite Copy. As before, select one or more virtual machines to backup and then click on Take Offsite Copy, you'll see a small popup And after the backup is done you'll see the status has updated real time, look for Successful Offsite copy Job done ! Summary Cons: I found the Altaro VM Backup console to be a little bit confusing at times necessitating calling their support number (please change the hold music) What was not immediately clear from the console was that in order to backup to the cloud, you must first define an on-premise (disk or network location) backup location as the primary location, and only after you've successfully backed up to that primary location, can you attempt the offsite backup. (I've given this feedback to Altaro directly.) Pros: Great quick support Altaro VM Backup is definitely one of the best Virtual Machine backup softwares out there today, and it's very competitive The ability to backup to Azure Cloud Storage is a great addition I'd recommend you give it a test run yourself: http://bit.ly/altaro-download Recommended reading Microsoft Azure storage pricing details - https://azure.microsoft.com/en-us/pricing/details/storage/ Microsoft Azure replication options - https://docs.microsoft.com/en-gb/azure/storage/storage-redundancy Altaro support for setting up Azure Cloud Storage - http://support.altaro.com/customer/portal/articles/2814316 Altaro VM Backup best practises - http://support.altaro.com/customer/en/portal/articles/2268483-best-practices-for-setting-up-altaro-vm-backup?b_id=14453 Microsoft Azure Storage Explorer - https://azure.microsoft.com/en-us/features/storage-explorer/ Note: Some of you may have already noticed that Altaro is a sponsor of windows-noob.com, and that is a good thing, please return the favor and use their software.

glad to see you are doing my lab, it is intended for use in a Lab environment, i'd recommend consulting with a PKI expert to get the answers to your capolicy.inf question that said, here's microsoft documentation on the subject https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file

In a previous series of guides I showed you how to configure PKI in a lab on Windows Server 2016. In another series, I also showed you how to install System Center Configuration Manager (Current Branch) version 1802 on Windows Server 2016 with SQL Server 2017. In this lab, I will show you how to configure SCCM to utilize that PKI environment. This series is based upon an excellent video by the talented former Microsoft Premier Field Engineer Justin Chalfant here. If you haven't seen it yet, do check it out. The intention here is that after you've completed this PKI enabled SCCM lab you can then use this in future guides, and to dig deeper into new technologies from Microsoft, for example enabling a Cloud Management Gateway and/or Cloud Distribution Point and using later on, using Co-Management. Note: To complete this lab you must first complete the PKI Lab series (8 parts) and then install a new virtual machine within that PKI lab running System Center Configuration Manager (Current Branch) version 1802 utilizing this series (4 parts), that installation of Configuration Manager will be in HTTP mode. In addition, you must configure the Software Update Point role (in HTTP mode) on CM01 See this guide (step 2 onward) for details. For details how to configure that, see this post. It will take some time to setup but you'll be glad you did. Also, don't do this in production without consulting with a PKI Expert. I don't claim to be one, I'm just helping you get it up and running in a lab. This is intended for use in a lab only. In part 1 of this series you created an Active Directory Security Group to contain your SCCM servers that host IIS based roles such as Distribution Point, Management Point and Software Update Point, you then rebooted that server after adding it (CM01) to the group. You then created 3 certificate templates for SCCM on the Issuing CA server (IssuingCA) and issued them so that they could be available to applicable computers. You verified that you had a GPO in place for AutoEnrollment before requesting the IIS and DP/OSD Certificates on the IIS Site System (CM01) using certlm.msc. Step 1. Edit bindings in IIS for the Default Web Site and WSUS Administration Websites On the SCCM server (CM01), start Internet Information Services (IIS) Manager, expand Sites so that you can see the Default Web Site and the WSUS Administration websites listed. Select the Default Web Site, this web site is where the management point, distribution point and other SCCM roles such as Application Catalog can be found (if they are installed). Edit bindings on the Default Web Site Right click on the Default Web Site and choose Edit Bindings from the options available. In the window that appears, select the https section (port 443) and choose Edit. In the SSL certificate dropdown menu, select SCCM IIS Cert. Click OK and then click Close. Verify changes made Once done, you can open up Internet Explorer and verify that it's reporting back in HTTPS mode for the default web site by browsing to the following addresses to verify the Netbios name and FQDN resolve in HTTPS mode. Click on the Lock in the address bar to get info about the connection. https://cm01 https://cm01.windowsnoob.lab.local/ Edit bindings on the WSUS Administration Web Site Repeat the above operation, on the WSUS Administration website (note that it uses port 8531 for https mode). click OK and Close when done. Step 2. Modify WSUS Administration SSL Settings WSUS itself requires some additional changes documented here (1) that we need to configure to allow WSUS to use HTTPS. In the Internet Information Services (IIS) Manager, expand sites and selct WSUS Administration. Select ApiRemoting30 under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply. Next, select ClientWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply. Next, select DSSAuthWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply. Next, select ServerSyncWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply. Finally, select SimpleAuthWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply. Step 3. Configure WSUS to require SSL In an administrative command prompt on CM01, browse to the location of WSUS installation files. cd C:\Program Files\Update Services\Tools Next issue the following command where CM01.windowsnoob.lab.local is the Fully qualified domain name of your ConfigMgr server hosting WSUS. WsusUtil.exe configuressl cm01.windowsnoob.lab.local The results are shown below: Step 4. Configure SCCM to use HTTPS In this step you will configure SCCM to operate in HTTPS mode. To do that, first bring up the site properties in the SCCM Console on CM01. To bring up the site properties, select the Administration workspace, select Site Configuration, select your site and in the ribbon choose Properties. Next, click on Client Computer Configuration, select HTTPS only from the options and then select Apply. Note: If you have both HTTP and HTTPS site systems in your environment, keep the second box checked (HTTPS or HTTP) and enable the Use PKI client certificate (client authentication capability) when available check box. Step 5. Configure Trusted Root Certification Authorities Note: If you fail to add the Root CA (ROOTCA_windows noob Root CA.crt) specified here, PXE boot will fail to download policy after entering the PXE password. In the site properties screen, click on Communication Security and then click on Set beside Trusted Root Certification Authorities, and click on the yellow star to add your Root CA, in this case, the Root CA for your lab (from the offline root ca), in other words point it to the ROOTCA_windows noob Root CA.crt file which is the Trusted Root Certificate for this site (the Root CA cert). Step 6. Verify that the Distribution Point, Management Point and Software Update Point are using SSL Next you need to verify the DP (and perform some additional configuration), MP and SUP roles are using SSL. To do this, select the Administration workspace in the console, click Site Configuration, select Servers and Site System roles, and select the Distribution Point role. Right click it and choose Properties to bring up the Distribution Point role properties. You should see that it is already configured for HTTPS. Next you need to add the certificate used by clients being imaged by operating system deployment in WinPE or for WorkGroup based clients, to do so, click on Import Certificate and select Browse, browse to the location where you saved the OSD Cert.pfx file (which you created in Step 5 of part 1 here), enter the password you specified, and click Apply. Click OK to close the Distribution Point role properties. For more info on the DP Cert requirements see - https://docs.microsoft.com/en-us/sccm/core/plan-design/network/pki-certificate-requirements Next, select the Management Point role properties, they are shown below, again, HTTPS is selected by default as you set it site wide with the HTTPS only option. When you selected HTTPS Only in the Client Computer Communication of the site properties, this initiated the Management Point to reinstall itself with the new settings, as you can see here in the sitecomp.log. In addition in the mpsetup.log you can see that it's configured for SSL Finally you can check mpcontrol.log this log logs the status of your Management Point, and in there you can verify that the Management Point is up and running and communicating OK in HTTPS mode and that it has successfully performed Management Point availability checks. Next, double click the Software Update Point role to review it's properties. Place a check in the Require SSL communication to the WSUS Server check box. Click Apply and click OK to close the Software Update Point properties. At this point open the WCM.log and look for a line that reads Step 7. Verify Client Received Client Certificate and SCCM Client Changes to SSL Logon to the Windows 10 1803 client and start and administrative command prompt, from there launch certlm.msc to bring up Certificates on the Local Machine. Browse to Personal and Certificates, and you should see the SCCM Client Certificate listed. Note: I assume you've already installed the ConfigMgr client agent using whatever method your prefer on the Windows 10 1803 virtual machine. Next, open the Control Panel and locate the Configuration Manager client agent in System and Security, and open it. If the client was just installed the Client Certificate will probably state Self-Signed (or None if you have just installed the client..). After a couple of minutes, close and then reopen the client and you should see that the Client Certificate states PKI. At this point, open the ClientIDManagerStartup.log in C:\Windows\CCM\Logs and you can see Client PKI cert is available. You can also verify client communication to the Management Point in the CCMMessaging.log and we can see it's successful in that communication. Job done ! You've successfully converted SCCM from HTTP to HTTPS using your PKI lab, and you've verified that the client is operating in HTTPS mode. In the next parts we'll look at the Cloud Management Gateway and Cloud Distribution Point. Recommended reading (1) - https://technet.microsoft.com/en-us/library/bb633246.aspx https://docs.microsoft.com/en-us/sccm/core/plan-design/network/pki-certificate-requirements https://www.enhansoft.com/how-to-setup-ssrs-to-use-https-part-1/

In a previous series of guides I showed you how to configure PKI in a lab on Windows Server 2016. In another series, I also showed you how to install System Center Configuration Manager (Current Branch) version 1802 on Windows Server 2016 with SQL Server 2017. In this lab, I will show you how to configure SCCM to utilize that PKI environment. This series is based upon an excellent video by the talented former Microsoft Premier Field Engineer Justin Chalfant here. If you haven't seen it yet, do check it out. The intention here is that after you've completed this PKI enabled SCCM lab you can then use this in future guides, and to dig deeper into new technologies from Microsoft, for example enabling a Cloud Management Gateway and/or Cloud Distribution Point and using later on, using Co-Management. Note: To complete this lab you must first complete the PKI Lab series (8 parts) and then install a new virtual machine within that PKI lab running System Center Configuration Manager (Current Branch) version 1902 utilizing this series, that installation of Configuration Manager will be in HTTP mode. In addition, you must configure the Software Update Point role (in HTTP mode) on CM01 See this guide (step 2 onward) for details. For details how to configure that, see this post. It will take some time to setup but you'll be glad you did. Also, don't do this in production without consulting with a PKI Expert. I don't claim to be one, I'm just helping you get it up and running in a lab. This is intended for use in a lab only. Step 1 - Create an Active Directory Security Group In this step you'll create an active directory group which will contain all your site systems that use Configuration Manager server roles which utilize IIS (Internet Information Systems) such as the below (1): Management point Distribution point Software update point State migration point Enrollment point Enrollment proxy point Application Catalog web service point Application Catalog website point A certificate registration point On the Active Directory domain controller (DC01), open Active Directory Users and Computers, and expand the windowsnoob organisational unit (OU) created in this Step 1, part 5 of this blog post. Click on Security Groups, and then right click and choose New, select Group. Give the group a name, SCCM IIS Servers. Once done, right click on the SCCM IIS Servers Active Directory Security Group, choose Properties and click on the Members tab, click on Add, for Object Types make sure Computers are selected. Add the Configuration Manager server (CM01) to that group. Once done, reboot the Configuration Manager server (CM01) using the following command otherwise you might get access denied when trying to request a certificate. shutdown /r Step 2. Create certificate templates on the Issuing CA In this step you will create three new certificate templates for use within SCCM by duplicating existing templates. Using the windowsnoob\Entadmin credentials, logon to the Issuing CA server (IssuingCA) and launch the certificate authority console (CertSrv.msc). In the three templates below, one uses the Web Server template, and the others use the Workstation Authentication template, you can verify which Microsoft certificate template to use by using the tables on the following blog post, of which i'm showing a screenshot below to make it clear. 1. SCCM IIS Certificate Right click on Certificate Templates and choose Manage. Scroll down to Web Server from the templates listed. Right click on the Web Server template and choose Duplicate Template. The Properties of New Template screen appears. Verify that the Certificate Authority Compatibility settings are set to Windows Server 2003. Note: When you use an enterprise certification authority and certificate templates, do not use the Version 3 templates (well you can but read this first). These certificate templates create certificates that are incompatible with System Center Configuration Manager. Instead, use Version 2 templates by using the following instructions. On the Compatibility tab of the certificate template properties, specify Windows Server 2003 for the Certification Authority option, and Windows XP / Server 2003 for the Certificate recipient option. (1) Click on the General tab and rename it to SCCM IIS Certificate. On the Request Handling tab, verify that Allow private key to be exported is not selected (default). On the Subject Name tab verify that the Supply in the Request is selected (default). On the Security tab, add the previously created Active Directory Security Group called SCCM IIS Servers and give it Read and Enroll access. Optionally you can remove Enroll from the Domain Admin and Enterprise Admins as it is mentioned in the docs. Click Apply to apply the changes and then close the Properties of New Template. 2. SCCM DP Certificate This template is used by the distribution point site system for Operating System Deployment (clients that are not domain joined). Next, right click on Workstation Authentication from the templates listed and choose Duplicate Template. The Properties of New Template screen appears. The Properties of New Template screen appears. Verify that the Certificate Authority Compatibility settings are set to Windows Server 2003. Click on the General tab and rename it to SCCM DP Certificate, change the validity period to something more reasonable, like 3 years. On the Request Handling tab, ensure that Allow private key to be exported is selected to allow us to export the certificate as a pfx file and we need the private key to do so, as we'll import that certificate into our console so that the clients can utilize it during imaging (workgroup members, to authenticate back to your site). On the Security tab, add the previously created Active Directory Security Group called SCCM IIS Servers and give it Read and Enroll access. Next, remove Domain Computers altogether. Click Apply to apply the changes and then close the Properties of New Template. 3. SCCM Client Certificate This template is used by clients to communicate with site systems. Next, right click on Workstation Authentication from the templates listed and choose Duplicate Template. The Properties of New Template screen appears. The Properties of New Template screen appears. Verify that the Certificate Authority Compatibility settings are set to Windows Server 2003. Click on the General tab and rename it to SCCM Client Certificate, change the validity period to something more reasonable, like 3 years. Under Subject Name verify that Build from Active Directory is selected. On the Request Handling tab, verify that Allow private key to be exported is not selected (default). On the Security tab, select Domain Computers and ensure that Read, Enroll and AutoEnroll permisions are selected. Click Apply to apply the changes and then close the Properties of New Template. The three SCCM templates are now shown below. Close the Certificate Templates console. Next you will issue these certificate templates. To do so, in the Certificate Authority (on the IssuingCA), right click on Certificate Templates and choose New, then Certificate Template to Issue. In the Enable Certificate Templates window, select the 3 previously created SCCM templates as shown below and click OK. They will now appear under Certificate Templates. Step 3. Verify Auto-Enrollment GPO is enabled for the Client Certificate In Part 8 of the PKI lab you enabled Auto Enrollment so that clients can request certificates automatically. As it is a lab, the setting is deployed in the default domain GPO. The setting is in Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies, and Certificate Services Client - Auto Enrollment. The setting should look like so (Enabled). Step 4. Requesting the IIS and DP/OSD Certificates on the IIS Site System On the SCCM server (CM01), which hosts all those IIS ConfigMgr roles, start certlm.msc from an Administrative command prompt. if you expand Personal, then Certificates, you'll see certificates issued to that computer, there will be a few by default. In the administrative command prompt, run gpupdate /force to pull down group policy changes...and refresh the view in certlm. Below you can see the SCCM Client Certificate template was used to generate this Client Authentication certificate. Requesting New certificates Next, you will request certificates from Active Directory, to do so, right click on Certificates and choose All Tasks then Request New Certificate. click Next at the Before you begin screen, and verify that Active Directory Enrollment Policy is selected before clicking Next. Select the SCCM DP Certificate and SCCM IIS Certificate from those listed (you already have the SCCM Client Certificate from AutoEnrollment). You'll notice that for the SCCM IIS Certificate, more information is required to enroll, Click on the message to enter this info. For Alternative Name, choose the DNS option and then click on Add to add the hostname and fully qualified domain name of your SCCM server (CM01). Note: If you want this server to be available via IBCM you could also add the publicly available FQDN of the site here (eg: cm01.windowsnoob.com) Next Click on General, and give this cert a friendly name so we can distinguish it in IIS later when we bind it. click OK, then click Enroll. It should state a status of Succeeded for both certificates. If not look at the details to find out what went wrong. Click Finish to exit. Step 5. Exporting the Distribution Point certificate Next you need to export the Distribution Point certificate so that during OSD the client can authenticate to the management point in WinPE. To do that, refresh the view in Certificates (certlm.msc) and then select the client authentication certificate created with the SCCM DP Certificate template. Right click and choose All Tasks, then select Export. In the welcome to certificate export wizard click Next and choose to export the private key. stick with the defaults and give it a password that you will use when you import it back into the SCCM Console, I used P@ssw0rd Save the cert to your desktop with a filename of OSD Cert.pfx and continue through that wizard until completion. You should see that the export was successful. That's it for this part, please join me in part 2 where we will complete the configuration of SCCM to HTTPS. cheers niall Recommended reading (1) - https://docs.microsoft.com/en-us/sccm/core/plan-design/network/pki-certificate-requirements

did you follow my guide 100% ?

i'd recommend you look at the work of fellow MVP, MikeTerrill, as he's blogged this exact scenario very well. https://miketerrill.net/2017/09/06/windows-10-bios-to-uefi-in-place-upgrade-task-sequence-using-mbr2gpt/

if you have access to teamviewer i can remote in and help, do you ?

thanks I appreciate it ! as regards the %date% issue, can you tell me if you are you using MDT integrated with ConfigMgr or not ? as regards the progress bar not showing up, you probably need to modify the pixel settings as described in the blogpost, i'll include that info again here for you Tip: If you have rendering issues with the popup on different devices then edit the call ResizeWindow(425,335,500,375) values and ResizeWindow Function to fit your specific needs, I don't have access to too much hardware to test this on. The popup is fixed, if you want the user to be able to move it change the line caption="no" to caption="yes". If you want to programmatically use it then add a Window.moveTo(x, y) line.

you can't pxe boot on site B because you can't install Windows Deployment Services on Windows 7, you'll need a DP that supports WDS (Windows Server operating system) in order to PXE boot at that location.

can you do a teamviewer session so i can remote in and see the problem ? if so, pm me the details, thanks if not, please raise a ticket with Microsoft CSS to get help thanks ! niall