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.
(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.
- Hunt around looking for the “Start” hotspot
- Click on Control Panel –> System and Security –> Windows Update
- Click on Check for updates
- A few moments later, we were presented with
Error(s) found: Code 80246003 WIndows update ran into a problem
- 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—
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!]
Step#3: Using regedit, delete the following Windows update registry entry
Step#4: Relaunch Windows Update and check for updates!
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.
- Type the URL for your Certificate Server
- You are prompted for administrator credentials
- You enter said credentials
- You are again prompted for administrator credentials
- You enter said credentials
- You are presented with a 401 Unauthorized error message
- You bang your head against your desk in frustration
The IIS server is not negotiating your credentials correctly.
- Logon to the server hosting the Active Directory Certificate Services
- Launch Internet Information Services (IIS) Manager
- Drill down and click on the the CertServ application
(Usually Server –> Sites –> Default Web Site –> CertSrv)
- Click and open the Authentication icon in the home view
- Click once on Windows Authentication to highlight the entry
- Select Providers from the action pain (located a the right of the IIS Manager)
- Move the NTLM provider to the top of the list. It *must* be the first enabled provider
- Restart IIS using IISRESET at the command prompt
Happy Certificate Issuing!