Semi Annual Channel 1903 Products

All admins should know this: If you are into the Semi-Annual Channel (like almost all of us), there are Windows Server 1903 and Windows 10 1903 new Products that you need to configure in WSUS / SCCM Software Update Point!

Coming Soon: Webinar “Always Up To Date with Windows 10 and Windows as a Service”

So last January 2018, after our talk in Microsoft Tech Summit held at the Marina Bay Sands, Jay-R Barrios and I recorded this video in the Microsoft Singapore offices.

I will post the link here once Microsoft releases it!

Often Overlooked Step when Configuring WSUS to Use SQL Server Always On

Documenting this issue on my personal tech blog because I got stuck with this for the past couple of weeks.

Scenario

• Windows Server 2016, for ConfigMgr Primary Site Server and multiple Software Update Points
• Multiple SUPs mean multiple WSUS
• WSUS Servers using a common SQL Server, per Microsoft best practice
• SQL Server is running Always On AG

 

Problem

Once all the WSUS Servers are configured, and the SUSDB is added to the Availability Group, both WSUS still looks ok. But when you execute failover, one or all all of the WSUS will fail.

 

Possible Reason

When you run the postinstall of WSUS, it configures the SUSDB, and adds the required logons on the current Primary Replica. But when you add the SUSDB into the Availability Group, the logons are not created on the current Secondary Replica(s) as of that time. Therefore you have to add a logon on all SQL Server Replicas of all WSUS Servers that will use the said SUSDB.  This is an often overlooked step, as per this forum post.

I haven’t seen an official support statement for or against using WSUS in an AlwaysOn availability group.

That said, as the only way you’re going to be able to make use of an AlwaysOn (unless it’s part of a System Center deployment) is by changing the database settings found in the registry under “HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup” (based on WSUS on Server 2012 R2), so I doubt it’s something they’ve seriously thought about.
In principle, the implementation steps would look like this:
1. Set up WSUS as per normal using the actual hostname of the initial SQL Server.
2. Take a back up of the WSUS database (a pre-requisite for including in the availability group).
3. Add the WSUS database to the preferred availability group.
4. Create a login for the computer account of the WSUS server on each SQL Server that is part of the AlwaysOn group (an often overlooked step until a failover actually occurs).
5. Stop the WSUS service.
6. Update the registry settings.
7. Start the WSUS service.

Referencing myself on the existing logins of the current Primary Replica, I created logins on the other Secondaries for all my WSUS Servers, and have given them public, securityadmin and sysadmin roles. My multiple WSUS worked after this step.

And when I say “works,” it means that I can open the WSUS console

• Simultaneously on all WSUS Servers at the same time
• After failing over to all my Always On replicas

 

Summary:

This was how I setup my multiple WSUS (assumes Always On AG is fully setup)

1. Create WSUS1, use SQL and connect it to the AG Listener
2. Create WSUS2, use SQL and connect it to the AG Listener
3. Configure SUSDB for Always On requirements (Full Recovery Model, perform Full Backup)
4. Add SUSDB to Availability Group
5. Add all the necessary logins of all WSUS Servers on all SQL Server replicas
6. Test
   • Connect WSUS1 and WSUS2 consoles, both should display properly
   • Failover one by one to all SQL Replicas, both WSUS consoles should still  display properly

Hope this helps!

jay paloma  |  10 sep 2017  |  singapore

SCCM 1606 SQL Server Views Documentation

If you are working on SCCM custom reports, you may have wished that there should be a reference out that you could use as reference to navigate through the countless database views available in SQL Server for SCCM. There is in fact such a reference, published by Microsoft last November 2016

Download the SCCM ConfigMgr SQL Views reference from here: https://gallery.technet.microsoft.com/SCCM-Configmgr-2012-R2-SQL-5fefdd3b

Other useful references

• SQL Server Views in System Center 2012 Configuration Manager
• Hardware Inventory SQL Views
• Discovery SQL Views
• Software Update SQL Views

jay paloma  |  26 mar 2017  |  singapore

Surface Pro 4 Issue: Availability of AAAA Battery

I purchased my Microsoft Surface Pro 4 last December 2015 in Funan in Singapore (that store was still open during that time), and on December 2016, the SP4 pen battery gave out. Which prompted me to look for the required AAAA battery. I was in Manila then.

Unfortunately I cannot find any. I am now on a mission to hunt where to buy these rare AAAA batteries and will post an update to this blog post if I manage to get one, be it in Manila or when I’m back in Singapore.

It is hard to find this battery in Manila

 

jay paloma  |  06 dec 2016  |  manila

2017: The Year that SHA1 Gets Deprecated

Hello all! Wishing everyone an advanced Happy New Year greetings! And what’s so special about 2017? Quite a number of vendors are deprecating SHA1! So if your job involves managing your company’s CA, then I sincerely hope you managed to have gotten rid of all your SHA1 certs.

References:

• Microsoft: An update to our SHA-1 deprecation roadmap
• AUSCert: Deprecation of SHA1 Certificates
• Mozilla: Phasing Out Certificates with SHA-1 based Signature Algorithms
• SHA1 Deprecation: What You Need to Know

 

jay paloma  |  05 dec 2016  |  manila

SCCM User State Migration: Error 0x0004005 during User State Restore

Scenario

• In SCCM Build 1606, you intend a side-by-side migration with User State Migration.
• You execute your Capture User State Task Sequence on the SOURCE machine
• You build your TARGET Machine
• You create a Computer Association between your SOURCE and TARGET machines in Configuration Manager Console > Asset and Compliance > User State Migration. Now you have two computer associations using the same Source Computer:
  • the one with Migration Type = In-place and Destination Computer is itself,
  • another with Migration Type = Side-by-side and Destination Computer is your intended TARGET machine (see picture below).

 

Example of creating a Computer Association after User State Capture. I performed a User State Capture on MININT-8AA13J1, resulting in the association with In-place Migration Type. Then I created an association between MININT-8AA13J1 and OSDTEST03.  When I performed the User State Restore on OSDTEST03, it resulted in a 0x0004005 error.

 

• You execute your Restore User State Task Sequence on the TARGET machine and get the following error.

Task Sequence: Restore User State has failed with the error code (0x00004005). Please contact your system administrator or helpdesk operator.

Resolution

You need to create your Computer Association between the two computers before you perform the user state capture on the SOURCE machine.

Sorry guys, not too many screenshots here. However, I tried it in my lab and it works. Leave a comment if this writeup solved your problem.

jay paloma | 5 nov 2016 | singapore

Windows 10 Time Service Assigns Wrong Time

4 August 2016. Currently banging my head on this issue. Will update this post once I find a solution. The picture flow is from the upper left picture then go clockwise.

Picture 1 shows correct time. Then just to be sure I synced the time with the domain (#2), which shows confirmation (#3), but when I started the Windows Time Service (#4), the time changes to the wrong date and time, which is probably the date and time when I built this VM.

Environment: Hyper-V guest with SCVMM. Guest is NOT synchronizing with the Hyper-V host. I have 3 Windows 10 machines on two separate Hyper-V hosts displaying the same behavior, which rules out the Hyper-V host.

 

 

UPDATE
Since it’s the Windows Time service that, for some reason, reverts the clock to its build date and time, then shutting down and disabling the service ensures that the date and time are in the last correct setting.

Caveat: you have to manually sync time by issuing the following command from an elevated Command Prompt: net time /domain /set /yes

ConfigMgr Automatic Deployment Rule Fails with Error Code 1326 if Source WSUS is not a Domain Member

Behavior

ConfigMgr infrastructure uses a WSUS server in the DMZ which is not a member of the domain, as shown in the figure below:

If you use Automatic Deployment Rule, the sync fails with the following:

• Error code 0X87D20417 in the SCCM Console
•  “Failed to download the update from UNC content source. Error = 1326” in ruleengine.log.

Configuration Manager Console Automatic Deployment Rules showing error code 0X87D20417

 

ruleengine.log showing error 1326

Meanwhile, patch metadata is successfully transferred over to ConfigMgr when you sync software updates. Manual patch synchronization by downloading to the Deployment Package is also successful

Cause

The top-level ConfigMgr server attempts to access the shared WsusContent folder in your DMZ WSUS using the computer account of your Primary Site Serveror CAS, and fails because it is denied access. On your DMZ WSUS, you cannot grant access to the CAS or Primary Site Server or make them a member of any local group.

Resolution

You can choose from one of the following options if you intend to use Automatic Deployment Rules

1. 1. Copy the contents of \\dmz_wsus\WsusContent to a shared location which is accessible to your top-level ConfigMgr server (CAS or Primary Site Server), and sync the ADR from that location
2. Make the DMZ WSUS server a member of the domain and ensure that the top-level Site Server (CAS or Primary Site Server) is a member either of the local Administrators group or the WSUS Administrators group.

Remember, this is only an issue if you use ADR. I haven’t done testing on a normal non user-initiated SCCM update sync. You might want to give me feedback if this error shows up on non user-initiated update sync.

Products

• System Center 2012 R2 Configuration Manager SP1
• Windows Server 2012 R2

jay paloma  |  1 may 2016  |  singapore

This post is provided “AS-IS” and makes no warranties and confers no rights

“Does not support virtual hard disk sharing” Error when moving Hyper-V VMs

Error Message:

“The storage where the virtual hard disk is locaed does not support virtual hard disk sharing” error when creating VMs or moving VMs from one Windows Server 2012 R2 Hyper-V host to another (unclustered). These two machines are managed by System Center Virtual Machine Manager, but I am trying to test VM Migration from the Hyper-V Console because it kept failing in SCVMM.

My Resolution

Stop mucking around with the Hyper-V console when it is be part of SCVMM! Because I turned on the Replication feature (not sure if there is an SCVMM counterpart for this), migration stopped working. So the resolution is disable the Replication feature.

Good old patience and troubleshooting!

I did not find any published resolution to this problem and am already contemplating on rebuilding the lab. Importing VMs also did not work (exporting did work on the two hosts that are a member of SCVMM). I tested importing on a HV host that is not part of SCVMM — it worked! I compared the settings and the difference was that I enabled the two HV servers in SCVMM as Replica Servers. Once I switched off this feature in Hyper-V and tested Migration in HV Console, everything worked.

I am now testing migrating using SCVMM. I will update this post on the results. It’s already 1AM in Singapore and I had a long day.

NEXT DAY UPDATE: successful VM movement using SCVMM. Problem has really been solved. Have a nice day!

jay paloma  |  27 apr 2016  | singapore

Information is provided “AS-IS” and makes no warranties and confers no rights.