Maximus Minimus's questions

My SCCM hierarchy has three Distribution Points and I am adding a fourth.

The new Distribution Point is added successfully, and when I check Content Status I see that all of my content items are now properly targeting all four Distribution Points, with the exception of one package:

• Microsoft Corporation Configuration Manager Client Piloting Upgrade Package

This package still only targets the original three.

When browsing through the Packages list (via Software Library | Packages) this Package is not visible.

Using PowerShell, Get-CMPackage with the ID of this package returns nothing. Likewise Get-CMPackage | ft PackageId doesn't list the package ID (it does list my other packages correctly).

How do I amend this package to target the new fourth Distribution Point?

It's SSL certificate replacement time, and while I could, for my Windows servers, do this the tedious way (Certificates mmc, import manually), I'm looking for something I can automate via some PowerShell scripting.

I know about Import-PfxCertificate, and to import a .pfx I'd do something like:

$pwd = ConvertTo-SecureString -String "PrivateKeyPasswordGoesHere" -AsPlainText -Force
Import-PfxCertificate -Password $pwd -FilePath "\\path\to\pfxfile\pfxfile.pfx" -CertStoreLocation Cert:\LocalMachine\My -Exportable # optional if i want the private key to be exportable

This is all well and good, but unlike the manual tedious way it only brings in the entity certificate itself; it doesn't bring in any other certificates in the full chain (root, intermediates, etc).

It looks as if I may be able to do something with Get-PfxData, which "extracts the content of a Personal Information Exchange (PFX) file into a structure that contains the end entity certificate, any intermediate and root certificates", but Import-Certificate has a mandatory FilePath parameter, so I can't pipe the output of Get-PfxData to it.

I've used Get-PfxData to verify that the PFX does indeed contain the full chain.

I've also tried the following approach:

• Import manually to the Certificates mmc.
• Use Export-PfxCertificate to export the full chain (which one must assume does so in a format that's consumable by Import-PfxCertificate).
• Use Import-PfxCertificate to import the exported certificate.

But again, Import-PfxCertificate does not bring in the full chain.

Any other options for cracking this nut?

Two Exchange Servers and three Domain Controllers in the same AD site. All Domain Controllers are GCs.

Exchange is Exchange 2016 on Windows Server 2016. Domain Controllers are Windows Server 2019.

On Exchange01 everything works fine - using the Exchange Management Shell I can issue commands such as Get-Mailbox successfully, and Get-DomainController returns a list of all Domain Controllers.

Exchange02 gives "Could not find any available Global Catalog in forest".

On Exchange02 I can use regular PowerShell and issue commands such as Get-ADUser which confirms AD connectivity is OK for this server.

On Exchange02 I can do Get-ADForest | Select-Object -ExpandProperty GlobalCatalogs and it correctly lists all Global Catalogs.

The evidence indicates that this is localised to Exchange connectivity to AD on Exchange02.

This has only happened over the last day and there have been no changes to the environment.

So - how do I fix it?

SCCM 1710 with KB4086143 Hotfix Rollup, running on Windows Server 2012 R2, configured with a Software Update Point and WSUS on the same server.

Neither the SUP nor WSUS were ever configured to download Express Updates. Client policy is set to not use Express Updates.

A "baseline" Software Update Group and Deployment Package are created which - correctly - do not contain Express Updates.

An Automatic Deployment Rule is created and this is the one that persistently downloads Express Updates; a full set of updates for the previous month (only!) is 65gb. Fine-tuning it to only include Security Updates is 25gb.

Trashing and recreating the ADR makes no difference.

I'm not prepared to trash and recreate the SUP and WSUS unless I can have reasonable assurance that it will resolve; time is money and I've already wasted enough.

I've seem rumblings on TechNet that this is a bug that should be fixed in 180x; I am willing to upgrade to 1802 but we're in the middle of a deployment right now and team members would be annoyed. I'll take that on the nose if 1802 resolves, but can't find any indication in the release notes or KBs that it does.

A crazy idea is to build and configure another WSUS, use that as an upstream, and beat on it until it doesn't download Express Updates. I've no idea how it would work in practice, I'd prefer a cleaner fix, but I'm willing to try it as an interim measure.

Are any of these options viable, recommended, or is there another, better way of taming this beast?

Prospective answers may assume that this environment was built correctly and in accordance with documentation and recommended best-practices.

The scenario is: Server1 and Server2, both running Windows Server 2012 R2 at the same patch level, are currently in a load-balancing cluster. Server1 has application issues and advice is to replace it. It's been taken out of the cluster and Server3 is being provisioned as it's replacement.

When Server1 and Server2 were originally built no patch-management solution was used. They were built at the same time and just patched to the then-latest level.

The objective is to patch Server3 to the same level as Server2.

As mentioned, no patch-management solution is available.

Going through the updates on Server2 one-by-one and applying them to Server3 is, of course, an option, but we should be able to do something better than that. It is 2017, after all.

It is possible to retrieve a list of all updates on Server2 via PowerShell and by KB number, and this list is available.

But how to then download and apply these updates, and only these updates, to Server3?

Initial research has turned up a number of Windows update scripts, both VBS and PowerShell, but they all fail at the critical requirement that not all current updates must be applied.

Bringing Server2's patch level to current, then also the same for Server3, is also an option but one which I'd prefer to avoid owing to having to schedule downtime/maintenance windows (there being no viable Server1 in the cluster) then a bunch of application testing. Let's keep that as a last resort.

So - what are my reasonable options for automating this in a sensible way, given the above constraints?

So about 3 months ago I "inherited" a Lotus Domino setup, and quite frankly, it's a mess. Historically, it's had 10 years of the primary focus being on development rather than on management and housekeeping (none of the latter was actually done, I had guys who'd left the place 11 years back still in admin groups), with a predictable end result.

Now, I know how to clean up a mess, but while I'm doing that I'm also keeping one eye on the future, and something that I'm interested in investigating is the possibility of Active Directory integration. It doesn't make sense to me - in 2009 - to have yet another bunch of systems that require yet another username and password, inviting people down the route of yellow-sticky-note-syndrome (not to mention doubling our user/password management overhead).

With clients being a mixture of browser-based and trad-client-based, I'm wondering how practical this is. Has anyone done it, and how well does it work? Do we get completely transparent authentication without requiring to even re-enter network credentials, do we still have to fool around with ID files (gack), can we add AD users to Domino groups, that kinda stuff.

The server is 8.0.2 (on 2003 Server), clients mostly 8.0.1 and IE6, database applications but not Notes Mail are used. What little info I've seen on IBM is incredibly vague on the whole topic.