Enabling Password Change in ADFS 3.0

I would like to start this off the same way that many posts on this topic do by defining the difference between password change and password reset.  Looking at the two terms they seem like the same thing, but in the wonderful nerdy world that we call our home they are two very different things.

Password Change, the topic of this post, is the ability for an Active Directory user to change their password when they know what their password currently is.  Password Reset is when an Active Directory user does not know their password and must provide alternate recovery methods, for example a phone number or security questions.  While Password Reset functionality is cool and completely possible with ADFS (psst Password Writeback), that will have to wait for another post.  Today we are focused on Password Change with ADFS, introduced in 3.0 to my knowledge, which is most commonly used for resetting expired passwords/newly setup accounts.  Without further ado, let’s dig into it.

1.  Start by logging into your ADFS server and opening AD FS Management.

2.  Expand out Service, select Endpoints, and scroll down to the Other section where you will find /adfs/portal/updatepassword/.

3.  Right click on it and choose Enable.  Restart the ADFS service and Password Change is now available on the corporate network!

4.  Chances are that you want to enable this for users on external networks (where it’s most useful).  Do this by right clicking the /adfs/portal/updatepassword/ endpoint again and selecting Enable on Proxy.  Restart the ADFS service again and Password Change will be fully enabled!

What is Service Pack for ProLiant?

If you have HP servers and you don’t know about Service Pack for ProLiant (SPP), you need to take a few and read this.  I’m not sugar coating anything, this post is mostly because I always forget the name of this dang utility and is nothing special.  So here’s the official description of what SPP does (source):

The Service Pack for ProLiant (SPP) is a comprehensive systems software and firmware update solution, which is delivered as a single ISO image. This solution uses Smart Update Manager (SUM) as the deployment tool and is tested on all HPE ProLiant Gen9 and Gen10 servers as defined in the Service Pack for ProLiant Server Support Guide found at www.hpe.com/servers/spp/documentation.

All in all, this little utility will update all your drivers and firmware for you.  Even better, it’s just an ISO that you create a bootable USB out of.  One thing to note is that you do need an active support agreement with HP Enterprise to obtain the software through official means.  Assuming you have that, check the documentation to make sure your model is supported and you’re off to the races!

Renewing Let’s Encrypt Certificates with certbot-auto

I had some trouble renewing a certificate on a web server today with a particularly “wonky” configuration if you will.  The standard certbot methods I would normally use just would not work for me so I had to dig a little deeper into the more “advanced” certbot setups.  This brought me to the certbot documentation where I read that the certbot-auto script might be able to help me out, so I gave it a shot and it worked!  I started by downloading the script and changing the permissions as instructed:

I threw it in a home directory, but that is really dealers choice.  Once I had that complete I simply ran the following command and was off to the races:

 

Sage 50 “Failed to switch Terminal Server to INSTALL mode…”

I think that anyone would agree that dealing with financial software is always a pain.  Today is no different!  All joking aside, the issues (yes with an “s”) began from the beginning of my journey to upgrade Sage 50 2017.2 to Sage 50 2018.1.

To be honest Sage has really tried to make this a painless process.  Should be as simple as downloading the update via the application GUI, closing the application to prompt the upgrade, and you’re off to the races.  If that worked as designed it really would be simple, not that the issues are that bad just frustrating.  Anywho, upon closing the application to upgrade I was presented with the following “error” message:

Rather bothersome considering I (obviously) was an administrator, but okay let’s just find the actual upgrade executable and run it as administrator.  I navigated to %InstallDirectory%\Sage\Peachtree\<CompanyName>\Updates and ran Sage50_2018.1.0.Upgrade.exe found there.  Simple enough right?  Of course not my young padawan learner, this is financial software after all.  I was then presented with the following error:

For starters, I love the typo “To swith” in the error message.  Spoilers, the switch doesn’t work.  This brought me to old faithful…Google.  I stumbled upon a Sage support article (found here) which provided multiple options for resolving this issue.  I chose the second option which had me do the following:

  1. Open up %TEMP%\RarSFX0\peachw\install
  2. Run _setup.exe as administrator
  3. Follow prompts to install

That did the trick for me, as such that brings this little post to a close.

 

P.S. If you have activation issues after the upgrade, bounce the box and try again.

Microsoft SQL Server Express – Create sa User Account without sa Account Credentials

I had some trouble coming up with a sensible title for this one, so sorry if it doesn’t make any sense.  Anywho, I had a awkward issue when I was migrating a database to a new server today…I didn’t have any administrative access over the SQL Server Express (2008) installation!  Windows Authentication would not give me administrative access even though it should have (yes the server was configured to accept Windows Authentication and SQL Authentication, and I was a Domain Admin/Local Admin), and the existing sa password on the server was a mystery that was impossible to solve.  So I took to the interwebs and came across this post on stackoverflow.  The comment by “40-Love” in particular held the solution for me, which I will detail below:

  • Close all SQL Server apps
  • Open services and stop all SQL services
  • Open the SQL Server service properties
  • Enter “-m” in the start parameters box
  • Open Command Prompt as administrator and do the following

  • Stop the SQL Server service
  • Remove the “-m” you added to the start parameters earlier
  • Start the SQL Server service

Wah-lah!  I now had an account on the SQL Server with sa access to do my business with.

Automated Windows Updates with PowerShell and PowerCLI

Holy cow it’s been a while!  Real life must be catching up with me or something, I am not sure.  Anywho, I’ve had this issue where I have never felt comfortable automating Windows Updates on my servers in case the worst should happen.  Seems like a reasonable concern right?  Well I finally got over it, did some digging, and found a suitable solution that I am comfortable with.

It really is quite simple.  I hijacked some PowerShell modules from Technet Script Center (found here) and then did some work with the PowerCLI module from VMware to take a snapshot prior to the updates.  Once it is done taking a snapshot of a VM (I pull them from an array) it will begin updates, and restart as needed.  I do not delete the snapshots in an automated fashion at this time, I just check everything is still good when I get in the office in the morning and then remove them all with PowerCLI (assuming there is no issues) as seen below:

Since I said I run this while I’m sleeping, I obviously just have it set up with Task Scheduler running with a service account I created with access to all the necessary servers and my vCenter environment.  Without further ado, I give you what I have coined “UpdateAutoPilot” below: