anyweb

read through my guide it covers at least one of your issues.

follow this series of guides (replace 1902 with 2203) and you'll be fine...

you are welcome, 1. the official docs are the place to start https://docs.microsoft.com/en-us/mem/configmgr/ 2. as long as it's Current Branch, you can upgrade in increments via the console, to upgrade follow the advice from my old post here 3. I'm not sure what scripts you are referring to...

dns is needed by the client(s) and servers so that they can all communicate with each other, for example the clients need to send state messages to the Management Point, aside from this, a network (whether LAB or Production) should always have working DNS otherwise you'll have problems with pretty much everything

ok it looks very like a DNS issue to me verify that DNS is working before trying again, you can do simple ping tests to the servers in question from a cmd prompt, or tracert/nslookup tests.

try it again now

looking at your error, the actual problem is connecting to the root\sms namespace to find the provider location take a look at this see does it give you some pointers https://docs.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/sms-administrator-console-connectivity-issue if it doesn't help try disabling the DCOM hardening. https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c

yup please share the script and i can test it in my lab, if you want email it to me niall@windows-noob.com

New research shows 50% of endpoints are at risk 600 CISOS, IT SecOps Directors, and Managers report that almost half of devices are vulnerable to attack because they are undetected by IT or have outdated operating systems. Thousands if not hundreds of thousands of devices at the edge need to work securely no matter where they are. But three significant factors are standing in the way: Device proliferation: 61% of respondents say distribution points have increased in the past 2 years and only 33% are confident they can reduce that sprawl. An expanding threat landscape: Only 39% of respondents believe their organizations are effective at preventing and detecting endpoint attacks. Rapid decentralization: 57% of IT professionals say that a remote workforce has made it difficult to deliver necessary security updates and patches to endpoints. So why is it that despite the average $4.3 million IT budget dedicated to endpoint protection ($31.50/endpoint) do only 34% of organizations have enough resources to minimize endpoint risk? The speed and scalability of their endpoint management solutions have everything to do with it. Get over 50 pages of peer insights in this year's Managing Risks and Costs at the Edge report from Ponemon Institute and Adaptiva.

is the password defined in a variable in the task sequence, if so, re-enter it

can you please attach the entire smsts.log file here so we can see what is failing ?

the last step it runs is installing some applications, Installing application 'Base Office 365 2019 v1902_SA_(Build 14131-20278)' does this app restart the computer unexpectedly ? after that it seems to have issues, i'm guessing your step occurs after this point ? can we see a screenshot of your task sequence with the step you are expecting to run ?

chances are you are not seeing the step as it has rolled over, as you have not provided any relevant logs it's hard to determine the issue, so.... if you want us to dig deeper, zip up ALL your smsts*.log files and attach them here, we'll take a look

you don't need to make any changes to SetTimeZone-GUI.ps1 however you should take a look at the synctime.ps1 script as it tries to sync from both on-premise (eg: your Domain) as well as other sources, therefore you might want to make changes in that script

scripts can only be downloaded from windows-noob.com by logged in members, chances are @Abnranger67x was not a logged on member when he tried to download it

please re-read the blog post, basically this allows you to easily let standard users (non-administrators) change (or confirm) their regional settings that are set during Windows Autopilot, this occurs AFTER Windows Autopilot is finished

why not try disabling DCOM hardening, > https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c.

can this be related to versions of Microsoft Visual C++ installed ?

Introduction Microsoft released another Technical Preview release, this time 2207, and it has a new feature, Distribution point content migration. According to the official blog post this will come in handy when you need to migrate your distribution point content from one dp to another, in particular because of the first 2 points listed below. As I don't have either (1) or (2) I will test scenario (3). Step 1. Satisfy the prerequisites One of the prerequisites is that the user performing the migration has the "Copy to Distribution Point" permission enabled under the Distribution Point permissions. As my user account is a Full Administrator, that requirement is already met. The other requirements are listed below. If you want to deprecate the source distribution point, make sure that the source and destination distribution points have the same boundary group. The destination distribution point should be installed already and able to receive the content. Step 2. Migrate a distribution point using Powershell As the current solution does not work in the Console, we need to use Powershell to do the migration. On the Configuration Manager server, open a Powershell cmd prompt via the console, and try the following Start-CMDistributionPointMigration -SourceDistributionPointName <FQDN for source distribution point> -DestinationDistributionPointName <FQDN for destination distribution point> for example... Start-CMDistributionPointMigration -SourceDistributionPointName cm01.windowsnoob.lab.local -DestinationDistributionPointName webserver.windowsnoob.lab.local as shown here... The fact that it didn't error was a good start. Step 3. Monitor the migration using Powershell As the ability to monitor this via the console is not yet available, you'll need to once again monitor things using Powershell. The command this time is Get-CMDistributionPointMigrationStatus -SourceDistributionPointName <FQDN for source distribution point> -DestinationDistributionPointName <FQDN for destination distribution point> Let's give it a try. Get-CMDistributionPointMigrationStatus -SourceDistributionPointName cm01.windowsnoob.lab.local -DestinationDistributionPointName webserver.windowsnoob.lab.local The result should tell you if it's in progress, completed and so on. Step 4. Monitor the content being migrated The docs incorrectly listed the cmdlet as Get-CMDistributionPointContentMigrationStatus but that doesn't work, see below. Here is a screenshot of the docs... (as of 2022/07/10), I've informed them of the error, so I'm sure it'll be fixed soon Using the power of the TAB key, I figured out the correct command and here it is: Get-CMDistributionPointMigrationContentStatus I think that the status (4) means that it's still in progress but I've asked the Microsoft Product Group for comment. As you can see below the source DP lists this packageID as a large package so it will take more time to complete. and sure enough, after more minutes in transit, the status changes from 4 to Success So there you have it, content migration from one distribution point to another using Powershell built into ConfigMgr works very nicely indeed, is that cool or what ? Related reading https://techcommunity.microsoft.com/t5/configuration-manager-blog/configuration-manager-technical-preview-version-2207/ba-p/3567090 https://docs.microsoft.com/en-us/mem/configmgr/core/get-started/2022/technical-preview-2207 cheers niall

interesting, what version were they running prior to this ?

great Nancy, what did you do exactly so others may learn

and if you rdp to one of these machines and launch the console, does it work ?

what does the SMSAdminUI.log tell you (on their pc) ?

the ruleengine.log should give you some clues as to why it's taking time to do what you expect, take a look at this old blog post which will hopefully give you some ideas about going deeper with your troubleshooting