How things have changed!

During a recent “office cleaning”, we stumbled across several old copies of PC Magazine.  Being the technologists we are, we just had to read the articles.  One specific article titled The 486: All That Power with No Place To Go really caught our attention.

This article demonstrates just how fast technology changed in the 90s and 2000s.

Enjoy!

(Click for larger view)

Recently, we introduced several Windows Server 2012 machines into our network environment.  Everything worked like a charm *until* we performed a Windows update.

The Scenario

1. Hunt around looking for the “Start” hotspot
2. Click on Control Panel –> System and Security –> Windows Update
3. Click on Check for updates
4. A few moments later, we were presented with

Error(s) found: Code 80246003  WIndows update ran into a problem

The Environment

• A brand spanking new install of Windows Server 2012
• WSUS Role installed on Windows Server 2008R2
  (WSUS 3.0 SP2)
• Policy enforced Windows update via WSUS server
• Plain vanilla network and configuration

— Research Happens Here—

The Solution

1st: Update WSUS Server to support Server 2012 and Windows 8
Download and install KB2734608 onto your WSUS Server.
Follow this link for details and download: http://support.microsoft.com/kb/2734608 

2nd: Reset Windows Update on your Server 2012 install
On the Windows Server 2012 install, perform the following steps to reset Windows Update:

Step#1: Shut down Windows Update via the following command line command

net stop wuauserv

Step#2: Delete the Software Distribution directory [Yes, the entire directory!]

%windir%SoftwareDistribution

Step#3: Using regedit, delete the following Windows update registry entry

HKLMSoftwareMicrosoftWindowsCurrentVersionWindowsUpdate

Step#4: Relaunch Windows Update and check for updates!

WARNING! This post was authored in 2012 and should no longer apply to most domains.  Unless you are running an NTLM only domain (really?), you should validate your SPNs!
See this Microsoft article for details on SPNs.

———————————————————————

At ArmgaSys, we consume SSL certificates at a ferocious rate.  Lync, Exchange, OWA, and UM all require SSL certificates to secure the multitude of communication channels.

While much debate rages around “Should I purchase a public certificate which will only be used on internal servers”, the reality in the field is many companies choose to leverage Active Directory Certificate Services.  This is done for one very good reason:  Internally generated (and trusted) certificates are free.

One of the issues we run into when requesting new certificates from ADCS is the dreaded 401 Unauthorized issue with Certsrv.

The Scenario

1. Type the URL for your Certificate Server
   http://[domain server]/certsrv
2. You are prompted for administrator credentials
3. You enter said credentials
4. You are again prompted for administrator credentials
5. You enter said credentials
6. You are presented with a 401 Unauthorized error message
7. You bang your head against your desk in frustration

Root Cause

The IIS server is not negotiating your credentials correctly.

Solution

1. Logon to the server hosting the Active Directory Certificate Services
2. Launch Internet Information Services (IIS) Manager
3. Drill down and click on the the CertServ application
   (Usually Server –> Sites –> Default Web Site –> CertSrv)
   
4. Click and open the Authentication icon in the home view
   
5. Click once on Windows Authentication to highlight the entry
   
6. Select Providers from the action pain (located a the right of the IIS Manager)
   
7. Move the NTLM provider to the top of the list.  It *must* be the first enabled provider
   
8. Restart IIS using IISRESET at the command prompt

Happy Certificate Issuing!