Thanks Kyle,

Might look into throttling workflow for first run through then allow it do run normally after the first pass though window.

Thanks Andy,

No backups run here, all DBs are replicated across 3 DAG members to negate 'the backup burden' with circular logging enabled on all to keep transaction logs in check every night.

I always err on the side of caution so think I will set the initial workflow timespan to 7 days and then drop it to default of 1 day after a complete

Thank you for confirming my fears! With regard to the rebuild task,..please be so kind as to advise...

Am I correct in assuming all certs issued from the existing PKI will remain active and functional on member servers providing the current Root CA, Sub CA and all other issued certs that chain back to them remain installed on member server certificate stores and have not yet passed their expiry dates...windows services should continue to function with these certificates just fine?

If the above assumption is correct, is it also correct to assume I can cleanly uninstall the current Subordinate CA and then use ADSI Edit to remove old Root CA references from AD. This will clean out old PKI but certs and services should still remain functional as they are locally present on all member servers?

Then...

I can drop fresh VMs and start to rebuild PKI from scratch, publish to AD, disseminate new Root CA and Subordinate CA certs via GPO, setup computer and user autoenrollment again and member servers and users will simply re-enroll with the new PKI accordingly.

We follow strict service IP alignment policies in our environments, hence I need to reuse the same IPs for Root Ca and Subordinate Issuing CA. This should not be an issue as I am cleaning out PKI and then rebuilding PKI while member servers run on existing locally present certificates...right?

Tnaks in advance...

durrie.

Thanks Any, my head was buried too far into the problem to come up for air and think...ADSI Edit is the obvious other option here.

ADSI Edit works, my ADM account is a member of all the required domain / exchange groups but still the organizational folder is a blank white tile with no access to the additional tabs!?

Hi Jason, thanks for the info, the link explains very succinctly how / why the issue occurs in 2107.

Is there anywhere we can track the progress for a new version / hotfix to this known issue?

I have very recently started the migration my site to HTTPS. Currently my site's "Communication Security" settings sit in the hybrid HTTPS or HTTP option so we can gauge when we might be ready to go full blown HTTPS only!

As such I want my team to easily see in the console view if any clients are still using self-signed certs so we can focus on addressing them and prep for HTTPS only cutover.

Hi,

I've had some success getting this behavior to go away by bypassing certain security GPO's

My gut told me this was the "Interactive Logon" messages which we apply to all of our domains in the default domain policy. This is the legal disclaimer message which users must click the OK button for on the logon screen. We also enforce the CTRL+ATL+DEL keys sequence as a policy to be able to logon.

So far my testing has proved successful by disabling only the CRTL+ATL+DEL keys sequence requirement in GPO for my RDS App hosts.

The RD App loads, connects and the "Show Details" button still lights up, but a second or two later the applications fully loads on it's own with no user intervention required.

I'd really appreciate it if you could test the same in your environment and let me know if this resolves the issue for you also...

Regards,
durrie

WIM is definitely distributed, says so on the package content status page.

I looked into the setting on the WIM. Changed the Data Access tab settings, I selected the option - "Copy the content in this package to a package share on distribution points" and gave it a share name.

Share now exists on all DPs, and the WIM exists there...

Now when I deploy the TS it gets to the "Apply Operating System" step, and then I can see in the DP resource monitor that the WIM is pulled from the local DP...however...

The second phase of this step "Deploying WIM" the progress bar goes all the way to 100% then pauses, then fails, with the network timeout error 0x80070002.

Hi Amandayou,

I discovered this Q&A article while looking for answers to the same issue as the OP.

I want to patch a SharePoint Server 2019 server in my organisation using our CM server & SUP.

I have enabled Office 2019 as a SUP category, created an ADR for Office 2019 and the ADR runs with no errors but no Office 2019 nor SharePoint Server 2019 patches are returned into my updates database.

From reading the above...are you suggesting I should rather be using the Office 365 Client category in my SUP settings and ADR settings if I want to update SharePoint Server 2019?

Thank you, I forgot about the corresponding .adml in my haste to get this working. I can now confirm all is in order after copying both the .admx and adml files over to the required SYSVOL locations.

Forgot to mention I have a mixture of Server 2016 / 2019 domain controllers. Domain forest functional level is 2016.

Is this DC OS mixture a potential problem here?

I have been trying to find a good excuse to replace all my 2016 DCs with 2019 which patche in a fraction of the time!

@FionaYan-MSFT - thanks for the advice - my settings were already to listen on ALL network interfaces.

It's a strange series of events but I managed to resolve this by.

1) Again disabling PXE entirely - for a second time!
2) Enable only the PXE Responder again.
3) Re-created my Boot Images.
4) Deleted all deployments on Task Sequences.
5) Redeployed all Task sequences to the "Unknown Computers Collection"

Seems to be stable now...and as an added bonus seems to deploy a lot faster than before too!?

Thanks for the help.

@RahulJindal-2267

No I have now managed to entirely remove WDS and PXE configuration, I then re-enabled PXE responder ONLY and the PXE boot is now working but not for all architecture types.

I'm using DHCP vendor classes and policy to specify PXE options in my DHCP. A lot of MEMCM reading suggests not to use these and use DHCP helper addresses.

Is that true even when the DP,DHCP and clients are all in the same subnet?

@FionaYan-MSFT

Thanks for the help so far, as requested, a quick round up and explanation of outstanding issue.

After completely removing PXE config and WDS, rebooting and then enabling only the PXE Responder service I am able to now boot but not ALL architecture types?

I use DHCP vendor classes and policies for PXE configuration because all my deployments happen in the same subnet no IP helpers configured nor required.

When I boot from legacy BIOS it all works fine - but asks me to press F12 to network boot.

However, now when I boot UEFI systems I now get prompted to approve the PXE request?

This seems like legacy WDS config hanging around to me? Where do you configure these options when using the PXE Responder service?

@FionaYan-MSFT

Thank you - realized the removal of WDS was not automatic so what I did was entirely disable the PXE option then I manually removed WDS and I rebooted.

Then I enabled PXE again with the PXE responder option.

I can see requests in the PXE log but I do not really see any errors jumping out at me, with that said I'm not well versed is reading this log so don't know what to look for?

P.S. Site health status is all green ticks - OK