WSUS 2012 Post Install Configuration Fails: Config File Did Not Contain A Value “Content Directory”

Installed the WSUS Server Role on Server 2012.  Installation completes successfully and it comes up with the post installation configuration wizard.  I click to start the wizard, and it fails immediately.  I open up the log file created and see the text below.

2013-08-12 14:17:06 Postinstall started
2013-08-12 14:17:06 Detected role services: Api, Database, UI, Services
2013-08-12 14:17:06 Start: LoadSettingsFromXml
2013-08-12 14:17:06 Start: GetConfigValue with filename=UpdateServices-Services.xml item=ContentLocal
2013-08-12 14:17:07 Value is true
2013-08-12 14:17:07 End: GetConfigValue
2013-08-12 14:17:07 Start: GetConfigValue with filename=UpdateServices-Services.xml item=ContentDirectory
2013-08-12 14:17:07 Config file did not contain a value “ContentDirectory”
2013-08-12 14:17:07 Microsoft.UpdateServices.Administration.CommandException: A required configuration value was not found in the system. This is usually caused by installing WSUS through PowerShell and not specifying a configuration file. Review the article Managing WSUS Using PowerShell at TechNet Library (http://go.microsoft.com/fwlink/?LinkId=235499) for more information on the recommended steps to perform WSUS installation using PowerShell.
at Microsoft.UpdateServices.Administration.PostInstall.GetConfigValue(String filename, String item)
at Microsoft.UpdateServices.Administration.PostInstall.LoadSettingsFromXml()
at Microsoft.UpdateServices.Administration.PostInstall.Initalize(Parameters parameters)
at Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments)
Fatal Error: A required configuration value was not found in the system. This is usually caused by installing WSUS through PowerShell and not specifying a configuration file. Review the article Managing WSUS Using PowerShell at TechNet Library (http://go.microsoft.com/fwlink/?LinkId=235499) for more information on the recommended steps to perform WSUS installation using PowerShell.

Well, that is strange.  During the installation process you specify the content directory, and although the Server Manager uses PowerShell cmdlets behind the scenes, I didn’t do the installation using the PowerShell.  I did some googling and came up with nothing, so on a hunch I just launched the WSUS console.  Well, that’s interesting, its asking for the content directory and the DB instance again.  I filled in the correct settings, clicked run, and a few minutes later the configuration was finished.  I verified this by opening up SQL Management Studio and seeing that the SUSDB had been created.

Migrating WSUS From Server 2003 to Server 2012

List of supported Operating System’s and migration scenarios is listed here.  In my case I am going to migrating a WSUS deployment from Server 2008 R2 running SQL 2005 to Server 2012 Standard with SQL 2008 R2 SP1.

Review considerations and system requirements can be found here.

First step is to install and configure the OS according to your organization’s standards (including updates).  Second step is to install SQL 2008 R2 with SP1.

After launching Setup from the .ISO file I got the error below.  Select Run the program without getting help.

SQLError

Of course, then I just got the error below.  Back to the drawing board!  Open up Server Manager and install the .NET Framework 3.5 Feature Role using your Windows installation media.

.NETError

Open up Server Manager and install the .NET Framework 3.5 Feature Role using your Windows installation media.  You may need to specify an alternate location (which is just really your CD-ROM path).  Mine was D:SourcesSxS

After that is done re-launch the setup and install SQL Server.  I am not going to go through all the steps here, the only pieces I installed were the Database Engine and the Management Tools.  Then apply SP1 to the SQL Installation.

While SP1 is downloading/installing go through the Preparing for Migration documentation here, including filling out the worksheet for the existing WSUS server.

Now, for the actual migration we are just going to be following the steps listed here.

In my situation I am migrating from a WSUS Installation on Windows Server 2003 x86 (Source Server) to Windows Server 2012 x64 (Destination Server).   First step is to install the Windows Server Migration Tools on my destination server using the PowerShell command below.

After that you need to create a folder containing those migration tools to use on your source server following the instructions here.  Make sure you get the create command to match your Source WSUS Server.  In my case the command looked like this:

Next, open the C:WindowsServerMigration folder you just created.  You should see a folder named similarly to mine which was SMT_ws03_x86.  Copy this folder to your Source Server.  Next, open a command prompt or PowerShell and change the directory to where you placed the folder above.  In my case it was C:SMT_WS03_x86 and run the following command to register Windows Server Migration Tools:

Next step is to migrate WSUS Update Binaries from the Source Server to the Destination Server, instructions for which can be found here.  For some reason the instructions aren’t in the original article, I had to click through about 7 different TechNet articles to find these steps.

On your DestinationServer open Windows Server Migration Tools (as administrator) and run the command below:

Make sure to specify a password you can remember!

On your SourceServer open Windows Server Migration Tools (as administrator) and run the command below:

In my case my Source Path was just D:WSUSWsusContent and my Destination Path was the same.  You don’t need to create the folder structure on the Destination Server, the Migration Tool will complete that for you.

While that runs your Source and Destination Servers will look like this:

DestinationWSUS SourceWSUS

You can also check on the progress of the migration by comparing the contents of the WSUSWsusContent folder on the Source and Destination Servers to see how much has copied over.  This is a screenshot of my Destination Server after about 15 minutes of migration.

WSUSProgress

Migrate SharePoint 2010 Site to SharePoint 2013 Site on New Server

I needed to migrate a SharePoint 2010 site on Server A to a SharePoint 2013 site on Server B.  Because my 2010 site was using classic mode authentication, there were some extra steps involved to make sure that user permissions were carried over.  Below are the steps I used to accomplish this.

Step #1:  Backup the content database of the site you will be migrating using SQL Management Studio and copy the database backup to Server B (or wherever your SQL Database Server is that the SharePoint site on Server B uses.  For me they are the same server).

Step #2:   Restore the database backup on Server B.  You can rename the database at this time if you need to.  For me the database backup was of the WSS_Content database, which already existed on Server B so I renamed the database to Infrastructure_WSS_Content as part of the restore process.

Step #3:  Create a classic mode authentication web application in SharePoint 2013.  This can only be done through PowerShell.  Using the Central Administration Tool will create your Web Application in Claims Authentication Mode, and after the migration you will have all kinds of problems with user permissions (as I found out the hard way).

Your command will be in the format

Where:

<Name> is the name of the web application being migrated
<ApplicationPool> is the name of the application pool assigned to the web application
<WindowsAuthType> is either “NTLM” or “Kerberos”
<ApplicationPoolAccount> is the user account that this application pool will run as
<HostHeaderName> is the host header for the web application
<Port> is the port the web application will be created in IIS
<URL> is the public URL for the web application

Not all of these are required fields, you can lookup the help file for New-SPWebApplication here for more information on the cmdlet.

My command looked like this:

Which then produced the following output:

SPMigrationWebApp

 

Step #4:  Delete the content database that was created as a result of the New SharePoint Web Application.  This is because we need to associate our existing site database with this new Web Application in the next step.  You can do this using the SharePoint Central Administration Web Site.

  1. Launch SharePoint 2013 Central Administration web site.
  2. Navigate: Application Management –> Manage Content Databases
  3. Select the web application created in Step #3 from the web application drop down located in the upper right of the browser
  4. Click on the Database Name which was created in Step #3, it will be named something along the lines of WSS_Content_(Insert Random Characters)
  5. Scroll to the bottom of the database information page displayed and check the Remove Content Database checkbox
  6. Click the OK button

Step #5:  Validate that the SharePoint 2010 site can be upgraded to SharePoint 2013.  Launch the SharePoint Management Shell as Administrator and run the command:

Mine looked like this:

You are going to get an error about claims authentication, you can ignore that.  Any other errors should be addressed before continuing with the process, especially if they are issues that say Upgrade Blocked:  Yes.

Step #6:  Mount the database for the SharePoint 2010 site to the newly created Web Application using the command:

Once again, mine looked like this:

You will get a counter below your command that will show the progress while it mounts the database.

Step #7:  IISReset

Step #8:  Browse to your SharePoint Web Application URL.  Your site should display (with a big banner across the top asking if you want to upgrade the site.  Ignore that for now).

Step #9:  Convert your 2010 SharePoint site to Claims Authentication.  Classic mode authentication has been officially depreciated by Microsoft.  If you migrated a classic mode authentication based content database, it is strongly recommend you convert the database to claims based using the Convert-SPWebApplication PowerShell command:

Mine looked like this:

The result looked like this:

ClaimsWarning

Step #10:  Do another IISReset.  Browse to your site.  Click the banner at the top to upgrade and follow the steps.  Depending on the size of your site it can take quite a while to upgrade the site.

 

Fun With Printers and Group Policy Preferences

Had some fun the last two days trying to setup a HP LaserJet 4300 printer to be deployed via Group Policy Preferences to our work at home users utilizing a Citrix Xen Desktop environment.

This post is mostly for my notes in case I run into this again, but hopefully someone may find it useful.

1.  Your printer, even if it’s a TCP/IP printer, needs to be shared through a print server

2.  When you setup the printer on the print server, especially if it’s an HP printer, make sure under advanced settings that the Winprint Print Processor is set to Raw.

Raw

 

3.  This next step may have just been because the printer in question is a little older.  My Print Server is Server 2012 Standard, and the Xen Desktop clients are Windows 7 Enterprise x64.  The driver the server installed by default for this printer seems to be a Type 4 printer driver which won’t work.  I had to uninstall the printer and during the reinstall check the box for “Auto detect the print driver to use” and then browse to the drivers I had downloaded specifically for the Windows 7 x64 Enterprise OS.  I found this information in a TechNet article here.driver

4.  In a GPO you need to configure the Computer Configuration -> Administrative Templates -> Printers -> Point and Print Restrictions to disabled.  This will stop the pop up about downloading a driver from the server from showing up (or being suppressed depending on user rights).    Credit for this goes here since it was the first place I came across it.

5.  Item-Level Targeting using a security group works amazing.  I needed to create a security group for only a section of our Work at Home users to default to and use a different printer, and the Group Policy Preference GPO worked like a charm.

6.  The “Local Name” setting is the name the printer will display as to the user on the computer

PowerShell: Add Domain User to Local Administrators Group on All Servers In An OU

A co-worker needed to add a specified user to the local administrators group to all the servers in a specific Organizational Unit (OU), across 3 different sub-domains. Because of the different domains and service account names the script required that I prompt the user for input. After several hours (I am still very much learning PowerShell), this is what I came up with, and it worked like a charm.  Any suggestions/recommendations are greatly appreciated.

This blog was extremely helpful in piecing together the last parts that I needed.

PowerShell: Make Changes to CSV for Import Into ADLS Instance

We have an Active Directory Lightweight Directory Services (ADLS) instance that houses users for a custom application.  When new users need to be added to the instance we get a spreadsheet with the user’s names and their usernames.  I needed to figure out a way to import this .CSV, add columns with the appropriate information for import into the ADLS instance.

This is what I came up with.  If there is a “better” or more compact way to do this please feel free to let me know how to do so in the comments.  This is one of the first PowerShell scripts I have ever written and I have a lot to learn.

 

Updating PowerShell v3 Using a Proxy

Because my company uses a proxy to access the internet, the Update-Help doesn’t work in PowerShell.  And since it’s a company wide proxy, I can’t just go to a machine without it and download the help files and then import them into PowerShell.  After some digging around I found the solution below.  It’s not marked as the answer in this TechNet article, but it did the trick for me.

$webclient = New-Object System.Net.WebClient
$creds = Get-Credential
$webclient.Proxy.Credentials = $creds
update-help

Exchange 2010 Database Rapidly Increases in Size

Situation:
Windows Server 2008 R2, Exchange 2010 SP1 upgraded from Exchange 2003.  I should note that this upgrade occurred long before this issue happened.  The Exchange server is virtualized on VMWARE ESXi 5.0 Update 1.
Problem:
Thursday, May 31st, at midnight I received an alert that the Datastore my Exchange Database sits on was at 90% capacity.  This was odd because my Exchange Database had been right around 250GB for the last 9 months and the Datastore was 500GB in size.  Somehow it was up to 480GB.  After verifying there was no unusual activity, errors in the event logs, or backup snapshot issues, I doubled the size of the Datastore and went back to sleep.  When I got into the office the next day at 7AM, the Database was up to nearly 600GB in size. Clearly something was not right.
Solution:
Short version:  Install Exchange 2010 SP2 and all the rollup packages.  I ended up getting Microsoft support involved and this is a known issue for Exchange 2010 SP1 and is resolved with Exchange 2010 SP2 Rollup 1.
Longer version: 
For no apparent reason my Exchange Database was increasing by 1-2 GB every 10 minutes.  What started as a 250GB Mailbox Database ended up as a nearly 750GB Database in less than 36 hours.  Multiple server reboots did nothing to resolve the problem.  No users were experiencing issues and there were no errors or warnings of any kinds in the event logs.
Doing some research and reading online, it appeared the issue was possibly caused by a corrupt Mailbox and that moving the Mailboxes to a new Mailbox Database would resolve the issue.  While doing the move, the “old” Mailbox Database continued to grow at the same size, but the “new” one did not.  Everything was looking good I thought.  However, 2 Mailboxes failed to move because of corrupt items.  I moved them successfully by just increasing the number of corrupted items to allow to 10.  No sooner had those 2 Mailboxes moved over than the “new” Mailbox Database started growing at the same rate.  OK then.  Back to the drawing board.
Doing some more research I found that there were Powershell commands that let you repair Mailboxes or the individual Mailbox Databases.  I ran the following commands on the two Mailboxes that had corrupted items and failed the original move.
New-MailboxRepairRequest -Mailbox -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView
New-MailboxRepairRequest -Mailbox    -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -archive
After those two commands finished, and the event logs showed there was no corruption issues I ran the command against the entire Mailbox Database.
New-MailboxRepairRequest -Database -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView
The event logs also showed that command hadn’t found any corruption either.  So now what?
A post of mine on the Microsoft forums (http://social.technet.microsoft.com/Forums/en-US/exchangesvrgeneral/thread/7de2b043-a5e6-494c-9b2a-5fe2552fa21e/) had gotten some responses indicating that the Exchange User Monitor would help to figure out what user(s) were corrupted and causing the issue.  I installed it, and ran it, but had zero idea what I was looking at and couldn’t find anything that was of much use in telling me how to use it.  Sidenote, if you run it once and close it, apparently it requires a server reboot to run it again.  Good times.
It was at this point, with the “new” Mailbox Database closing in 600GB and the overall size of the Datastore up to nearly 1.4TB at this point that I decided to get Microsoft support involved.  While he couldn’t tell me why the Mailbox Repair Request didn’t find or fix the corrupted Mailboxes, he was positive the issue was fixed in SP2 Rollup Update 1, and it was.  After installing both and rebooting the Exchange server after each installation the Mailbox Database immediately finished growing.
Next thing I did was to move the Mailboxes to another “new” Mailbox Database so that it was the proper size, and then delete the two “old” Mailbox Databases.  Everything has been stable and back to normal ever since the updates were applied.

Failed to Mount Exchange 2010 Database: An Active Manager Operation Failed

This is the error message I received on my Exchange 2010 SP1 Server when creating a new mailbox database:
——————————————————–
Microsoft Exchange Error
——————————————————–
Failed to mount database ‘DBNAME’.


DBNAME
Failed
Error:
Couldn’t mount the database that you specified. Specified database:  DBNAME; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)
. [Database:  DBNAME, Server: SERVERNAME.DOMAIN.COM].


An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)
. [ Database:  DBNAME, Server: SERVERNAME.DOMAIN.COM]


An Active Manager operation failed. Error: Operation failed with message: MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)
. [ Server: SERVERNAME.DOMAIN.COM]


MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)


To resolve the issue I ran the command below in Powershell:


  1. Set-ADServerSettings -PreferredServer



Also, it never hurts to check the following while you are at it.  It seems to also resolve the issue.

  1. Open EMC and right-click on “Organization Configuration”.  Choose “Modify Configuration Domain Controller”.
  2. Specify the domain and the DC.
  3. Open EMC and right-click on “Recipient Configuration”.  Choose “Modify Recipient Scope”.
  4. Specify the global catalog server.  Make sure it is the same as the chosen DC.

Default Microsoft Active Directory Certificate Services URL

For my own reference (since I spent 30 minutes figuring this out and couldn’t find it documented anywhere) and to hopefully save someone else time.

After installing AD Certificate Services Web Enrollment, you need a URL to go to request and download certificates.  But, what is that default URL?

http://SERVERNAME/certsrv/en-us

Where SERVERNAME is where the AD CS Web Enrollment is installed.