Jay Paloma's Tech and Music Blog

Sometimes, this writer can no longer distinguish between the two.

Posts Tagged ‘Microsoft

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

leave a comment »


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

Advertisements

Written by jpaloma

September 10, 2017 at 11:57 AM

SCCM 1606 SQL Server Views Documentation

leave a comment »


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

jay paloma  |  26 mar 2017  |  singapore

Written by jpaloma

March 26, 2017 at 6:56 PM

Surface Pro 4 Issue: Availability of AAAA Battery

leave a comment »


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.

sp4-pen-aaaa

It is hard to find this battery in Manila

 

jay paloma  |  06 dec 2016  |  manila

Written by jpaloma

December 6, 2016 at 4:14 PM

Posted in Microsoft

Tagged with ,

2017: The Year that SHA1 Gets Deprecated

leave a comment »


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:

 

jay paloma  |  05 dec 2016  |  manila

Written by jpaloma

December 5, 2016 at 5:23 PM

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

leave a comment »


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).

 

screen-shot-2016-11-05-at-18-13-53

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.

screen-shot-2016-11-05-at-18-20-46

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

Written by jpaloma

November 5, 2016 at 6:24 PM

My First ConfigMgr Automation with System Center Orchestrator

leave a comment »


Here’s my first System Center 202 R2 Configuration Manager automated task using System Center 2012 R2 Orchestrator

  • Download the required Integration Pack from this link from the Microsoft website.
  • Download the Windows Installer XML (WiX) Toolset (at least v3.5) from this website
  • Install the WiX Toolset
  • Open the System Center 2012 R2 Orchestrator Deployment Manager and Import the Integration Packs

Screen Shot 2016-04-23 at 20.21.21

 

Screen Shot 2016-04-23 at 20.21.53

  • Right-click on the Integration Pack and select Deploy IP to Runbook Server or Runbook Designer. This executes the Integration Pack Deployment Wizard

Screen Shot 2016-04-23 at 20.25.29

 

Screen Shot 2016-04-23 at 20.25.42

 

  • Open the System Center 2012 R2 Orchestrator Runbook Designer, and in Options select SC 2012 Configuration Manager

Screen Shot 2016-04-23 at 20.55.06

  • In Connection, click Add, and enter in the information needed to connect to your ConfigMgr. Server should be a Primary Site Server.

Screen Shot 2016-04-23 at 20.56.21

  • By adding the ConfigMgr Integration Pack, we have new activities pertaining to ConfigMgr available in our Runbook Designer

Screen Shot 2016-04-23 at 21.47.53

  • To test, let’s now create a new Rubook with only the Create Collection action. Here are the parameters of that Create Collection action

Screen Shot 2016-04-23 at 21.50.12

  • Run this Runbook. Check in Log History that it succeeded

Screen Shot 2016-04-23 at 21.26.41

  • Now go to the ConfigMgr console and confirm that the Collection has been created

Screen Shot 2016-04-23 at 21.26.57

That’s it! My first ConfigMgr automation with System Center Orchestrator!

 

jay paloma  |  23 apr 2016  |  singapore

Written by jpaloma

April 23, 2016 at 10:02 PM

Configuration Manager RBAC – Collections

leave a comment »


2nd Jan 2016, continuing with the doing-nothing-while-on-vacation series.

You can assign access Collection access to Administrative Users. However keep in mind the following:

  1. If your objective is to ensure limited visibility of collection results, then see to it that you do not grant access to the All Systems collection. You have to have what I call a Top-Level Collection in lieu of the default collections (including All Systems). Ensure that the membership of this Top-Level collection is limited to the objects you want the specific admin to see. Use specific conditions, e.g., OU membership, computer name, etc., to populate. Also keep in mind that the objects are still available in Queries, so if you really need to ensure non-visibility of objects, deal with Queries as well.
  2. Use this Top-Level collection as the limiting collection for all other collections that you would create. Do not use the All Systems collection because if the user account does not have access to All Systems, then the user account will always see 0 membership. Remember: the user does not have access to the Top Level collection (ergo, 0 members) and you created a collection that limits itself to the All Systems collection (again, 0 members), and you’ll get a collection of 0 members!

So for example you want to create an RBAC role to be able to deploy Applications and Patches to machines from the APAC region:

  1. Create an APAC Top-Level collection, using All Systems as its limiting collection using OU membership as its criteria.
  2. Create a second collection of with APAC Top-Level as its limiting collection, and add the additional conditions that it is a ConfigMgr client and it is a workstation OS . Let’s call this APAC Clients 
  3. Create an AD Group APAC Deployment
  4. Add this group in ConfigMgr Administrative Users, and grant access to the APAC Clients collection. Also assign it the RBAC Role nearest to the deployment role you want, or customize the role further to get the actions you want this role to perform.

Screenshots to follow once I’m back in my lab. Too bad I haven’t installed my ConfigMgr lab in Azure yet at this point in time.

jay paloma  |  02 jan 2016  |  manila

Written by jpaloma

January 2, 2016 at 7:15 PM