anyweb

ok an update on this, if you want it working right now then I'm afraid you'll have to delete it and start again from scratch (including uploading all the content) don't mess with cnames it's not supported, you might get it to work, but it's not supported so don't bother. I've given your experience as feedback to the Microsoft product group and they are taking the feedback seriously, sorry for the hassles...

can you share the cloudmgr.log with me, feel free to remove any references to your company in the log.

what does the connection analyzer tell you ?

have you tried looking at your distribution point configuration status in Monitoring ? what does that tell you also, why do you have a CAS and three primaries, are you managing 150,000 clients (or more) ?

my experience was back when I wrote the script used in this blogpost, and at that time, it was the only way I could get Windows Autopilot to work in our environment. Our environment has changed since then and no longer uses the same type of proxy, you could say now that it now resembles a transparent proxy and therefore there's no longer any need to use the script. if you can, avoid using Hybrid azure ad join, it's more trouble than it's worth. When I initially wrote the script it was so that we could test Windows Autopilot on the internal LAN, a lot has changed since then and we've learned a lot too. The best advice I can give you is to try modifying this script to work with your environment, or determine if you need it at all based on what happens in Windows Autopilot, maybe you can add exclusions for the urls used during Windows Autopilot, there are lots of options. as regards point 3, you could always use a different network (think of it as an enrollment network) to get your devices through Windows Autopilot OOBE and complete enrollment, you could then apply whatever network/proxy settings you want AFTER windows autopilot is complete using some of the methods I describe here

ok so the script will create a scheduled task for each user but basically won't do anything for defaultuser0, as that's not a real user, it's only used by Windows Autopilot during the ESP, so... after the Account Setup phase (user account) part of the ESP is done, and you logon to the desktop, what scheduled tasks do you see ?

hi @MagnusL I've tested it with AzureAd joined devices only as that's what we use, and it works fine in that scenario, so when you checked task scheduler can you show me what it did create ? ive not seen a defult0 user before, DefaultUser0 yes, but not the other one... did you heavily modify the scripts ?

there's only one way to find out, try it ! i recommend trying it out using a virtual machine connected to the same network as the network you intend to test, that way you can try different settings in the script on the fly

hi, the link works fine you just need to be logged in to download files from windows-noob.com

how did you configure WSUS, did you use SQL or SQL express, if you used SQL, which version ? have you looked at event viewer for more details ?

ok have you updated Server 2016 with the latest patches from windows update ?

is WSUS separate from Configuration Manager ? what version of Windows Server is it running on ?

Introduction I saw an interesting tweet from @brucesaaaa where he talked about issues observed in multiple tenants during Windows Autopilot enrollment with required Win32 apps. The following was seen for required deployments of Win32 apps during Windows Autopilot enrollment: ESP did not flag these apps as required Required apps took hours and hours to install App install output codes (like for reboots) were not working Problem The problem was investigated and narrowed down to the version of Microsoft Win32 Content Prep Tool that the technicians were using to create the Win32 apps. The is very easy to understand as many admins simply download the tool and re-use it over and over. I’m guilty of that too !, the app I created below was created with 1.8.2.0 and the current version is 1.8.3. I’m not sure what version of the app that caused their issues but as soon as they downloaded the latest version and repackaged their apps the problems went away. Analysis I did some checking with a Win32 app I recently created. If you rename the app from it’s original filename.intunewin extension to filename.zip you can extract the contents. Open the detection.xml file in the metadata folder. If you open the XML file in a suitable reader, you can see the version of the tool that it was made with by reviewing the ToolVersion property highlighted below in yellow. If you start the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) and use a -v it’ll show the version info. IntuneWinAppUtil -v I guess that Microsoft could force that people use the latest and greatest version of their tool by scanning that detection.xml file prior to accepting the file. Or at the very least inform the user of possible problems if they choose to ignore the fact. This should bypass any issues caused by using older versions of the tool to package the Win32 App. Interesting problem, let’s see where it goes ! cheers niall

i'm using the most up to date windows 11 and my taskbar doesn't autohide, i'd imagine lots of people would complain if that did happen without their involvement

i've never noticed that, are you sure you are not setting some policy/registry key for that ?

that's not how I read it, I interpret the docs mentioned above as you need to install the DP role on a computer in the untrusted forest, and open ports to allow for communication back to the trusted forest

I think this covers it.. Primary sites support the installation of site system roles on computers in remote forests. When a site system role accepts connections from the internet, as a security best practice, install the site system roles in a location where the forest boundary provides protection for the site server (for example, in a perimeter network). To install a site system role on a computer in an untrusted forest: Specify a Site System Installation Account, which the site uses to install the site system role. (This account must have local administrative credentials to connect to.) Then install site system roles on the specified computer. Select the site system option Require the site server to initiate connections to this site system. This setting requires the site server to establish connections to the site system server to transfer data. This configuration prevents the computer in the untrusted location from initiating contact with the site server that's inside your trusted network. These connections use the Site System Installation Account. To use a site system role that was installed in an untrusted forest, firewalls must allow the network traffic even when the site server initiates the transfer of data. Additionally, the following site system roles require direct access to the site database. Therefore, firewalls must allow applicable traffic from the untrusted forest to the site's SQL Server: Asset Intelligence synchronization point Endpoint Protection point Enrollment point Management point Reporting service point State migration point For more information, see Ports used in Configuration Manager.

if the other forest is untrusted: Install site system roles in that untrusted forest, with the option to publish site information to that Active Directory forest To use a site system role that was installed in an untrusted forest, firewalls must allow the network traffic even when the site server initiates the transfer of data. When a two-way forest trust exists, Configuration Manager doesn't require any additional configuration steps.

start here https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/communications-between-endpoints#bkmk_noforesttrust if you can't find what you need please explain what is missing

With the shift in the computing paradigm to the cloud, the Azure ecosystem is quickly becoming a critical platform for IT pros to grasp and adopt. But how do you make the leap while maintaining security, manageability, and cost-control? Whether you’re making new VMs directly in the cloud, have VMs in your own datacenter and are looking to migrate to Azure, or you’re looking to manage VMs with cloud-based tools regardless of where they live, The SysAdmin Guide to Azure Infrastructure as a Service (Iaas) will teach you to set up and maintain a high-performing Azure IaaS environment. Written by veteran IT consultant and trainer Paul Schnackenburg, Altaro’s free 100+ page second edition eBook covers how to create VMs, size them correctly, and manage storage, networking, and security, along with backup. You’ll also learn how to operate groups of VMs, deploy resources based on templates, manage security, and automate your infrastructure. There are also two new chapters on Automanage and Azure Arc to help you bring a lot of automation to IaaS, all lessening the burden on your time. One thing that has changed significantly over the past couple of years is the shift towards making IaaS VMs more like PaaS services. VMs are great but they require a lot of maintenance and care, whereas all the business is really interested in are the applications and data that run inside of them. This explains the popularity of PaaS services such as managed Kubernetes (AKS) and Azure Functions (serverless). If you’re new to the cloud (or have experience with Amazon Web Services and/or Google Cloud Platform but not Azure) this eBook will cover the basics as well as advanced skills. And given how fast things change in the cloud, it covers the why (as well as the how) so that as features and interfaces are updated, you’ll know how to proceed. Make the cloud work for you - download your free copy today!

did the event logs reveal anything about the problem ?

Introduction If you've been looking at my guides, you'll know that I've used httptriggers in functionapps to add functionality to Windows Autopilot, below are some examples of that. 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 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 or users to an Azure AD group after Windows Autopilot is complete but only when the device is marked as Compliant Using the updated & secure Retire My PC app via Company Portal These work great, but for security reasons the secret attached to the function app itself will expire (after 6 months by default) and should be renewed before that time. Trust me, I learned the hard way. Discovering the problem You might forget to renew the secret and that's when you'll notice things not behaving the way they should. I first became aware of the problem before Christmas, I came into work on the Monday, and kicked off some Windows Autopilot installs but they didn't work correctly. I noticed that the triggers responsible for adding devices to Azure AD groups after Windows Autopilot is complete, but only when the device is marked as compliant were no longer working. I started my investigation on a client with the issue, and the following was reported in the log file. One line jumped out at me, UPN not found, FATAL. Yeah, that doesn't sound good. I then logged into Azure and found the trigger responsible. I fed it with some known good values and looked at the output. The first thing to note is it output the same error (1), even though I supplied a known good UPN (2). Therefore, I knew the error UPN not found, FATAL was a red-herring. I also noticed that there were error code 401 (unauthorized) in the console output (3). That was my first clue ! Next, I select App Registrations in Azure Active Directory, selected the Graph_function app and was greeted with a red error on top showing me that a certificate or secret had expired. Clicking on Certificates and secrets, showed the expired secret. Fixing expired secrets Now that I identified the problem, it was time to fix it. In the Certificates & secrets section, click on + New client secret (1), give it a suitable name (2), select when it expires from the drop down menu (3) and finally Add it (4). The new secret will appear. Notice the expiry date. Now, copy the new secret value. Next, locate the trigger(s) that use the previous secret. It's stored as $AccessSecret in my httptrigger examples. Replace that expired value with the value you copied from the newly created secret and then save your changes. Job done ! Repeat the above exercise for each trigger that uses the expired secret. Conclusion Nothing lasts forever, especially secrets. Now that you know how to renew your expired secrets, maybe it's a good idea to look at your app registrations and take note of when they expire, and pro-actively renew them before they expire next time ! If you'd like to automate that take a look at Peter Klapwijk's post here.

interesting, did you raise a microsoft case to determine this ?

here's the error, verify that the source files are in the locations specified in your -source path, Add-WindowsCapability : The source files could not be found.

Introduction This is part 9 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 renewing expiring certificates. 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 5 times Enterprise Mobility MVP based in the UK and Niall is 11 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 part 3 we created the cloud management gateway and verified that everything was running smoothly. In part 4 we enabled co-management. With co-management, you retain your existing processes for using Configuration Manager to manage PCs in your organization and you gain the additional advantage of being able to transfer workloads to the cloud via Endpoint Manager (Intune). In part 5 we enabled the compliance policies workload and reviewed how that affected a co-managed computer. In this part we will enable conditional access and see how that can be used to deny access to company resources. In part 6 we configured conditional access and used it to deny access to company resources unless the device was encrypted with BitLocker. In part 7 we showed you how to co-manage Azure AD devices. In part 8 we enabled Tenant Attach and looked briefly at it's features. In this part we'll renew a soon to be expired certificate which we created about a year ago in part 2. 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 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 <- you are here Cloud attach - Endpoint Managers silver lining - part 10 Using apps with tenant attach A certificates validity is set in stone when it's created, and as time passes the certificates validity will eventually expire. When a certificate expires, anything that relied on it to approve communication will no longer work, so keeping a close eye on your certificates validity and noting when they expire is a good practice to avoid any disruption to services within your organization. Note: The Configuration Manager console (as of ConfigMgr version 2111) does NOT keep you alerted of the expiring certificate, so you'll have to keep track of it yourself by paying attention to those emails from your certificate provider. Digicert does however notify you by email about the coming expiration, at 90 days, 30 days and 7 day intervals. Step 1. Create a new CSR Note: You should avoid using the CSR generated during the initial certificate creation, as this is not secure and can compromise your SSL certificate usage. In Part 2 of this series, 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. Step 2. Reissue the expiring certificate Next, login to your certificate provider (in this case Digicert) and locate the soon to be expired certificate. To the right click on Reissue Now. In the window that appears paste in the newly generated CSR from step 1. Enter a reason why you want the certificate reissued and then click on Request reissue. Finally, click on Confirm request. At this point, you will see a summary screen like this, take note that to complete the process you'll have to prove ownership of the domain by clicking on Prove control over domains. We chose the option to use a DNS TXT Record (recommended). Copy the TXT record and then login to your Domain Name registrar (eg: godaddy) and select the domain name, then paste in the DNS txt record value, below is the record created from above. Note: If your domain name registrar is GoDaddy or uses the same UI as GoDaddy, you may need to temporarily delete any CNAME that matches the hostname prior to adding the TXT record. After validating the TXT record, you can delete the TXT record and add the CNAME back. This seems to be a bug in their UI. After creating the TXT record you can verify it with dnschecker.org, as shown here, this is helpful in troubleshooting whether your DNS record (TXT, CNAME etc...) is valid or not. 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. Step 3. Download the CRT After verifying that you own the domain, you'll be able to download the reissued CRT (certificate) from the certificate provider (eg: DigiTrust). Step 4. Import the CRT Next, import the downloaded CRT back into the Digicert tool by clicking on Import and pointing it to the extracted CRT file in the zip you downloaded. 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. Reconfigure the Cloud Management Gateway In the ConfigMgr console, select Cloud Services and select Cloud Management Gateway. In the CMG properties, choose the Settings tab and click Browse beside the currently expiring PKI certificate Point it to the previously exported PFX file and enter the password when prompted Click Apply, notice that the Certificate File will have changed The CloudMgr.log will record this old certificate deletion and the addition of the reissued certificate. At this point, the hard work is done and your certificate is reissued, and your CMG is reconfigured to use the new certificate. You can verify the CMG is working properly by running the Connection Analyzer. Job done, please join us in the next Cloud Attach blog post, early next year !