What Not To Do As A Manager – Volume 1

This is the first post in what will be a multi-part series about what not to do as a manager or leader.  For better or worse in the last year I have had the “opportunity” to witness a lot of things that I wouldn’t recommend any manager or leader do if they want to be successful. This particular example applies to any aspect of your life, not just the professional part.

One of the two jobs I worked at during my two year odyssey was a contract position for a large construction firm.  The job was to perform a remote Datacenter consolidation and standardization.  The subject of this post is the Project Manager for said project, we will call him Matt.

My second week there Matt took me to meet another guy on the Infrastructure team that I had been communicating with via email about some System Center Configuration Manager reports he was going to write for the project.  As we were leaving his desk Matt turned around and just flipped the guy off.  Right in the middle of everyone.  I was incredulous.  The guy who got flipped off?  He must have been used to it because he didn’t even acknowledge it.  For my part, I was so stunned I didn’t even say anything.  After about 5 seconds of Matt flipping him off without a response, Matt just walked away.  My only thought was “That was completely messed up.”  Trying to give Matt the benefit of the doubt I tried to convince myself that there must have been an inside joke or something involved.  However, his actions really bothered me and the fact I didn’t even say anything bothered me even more.

Fast forward two more weeks.  I’m sitting at my desk when Matt walks by on his way to lunch.  Neither one of us says anything to the other and right before he walks out the door to go to lunch, he turns back around, walks over and flips me off.  What makes this more incredible is that I shared the cubicle area with the other contractor so he witnessed everything I am about to transcribe.

Me (sarcastic voice):  “Wow Matt, you are really cool!”

*5 second silence while we stare at each other*

Matt:  “Hold on I’ve got something else for you”

*reaches his other hand into his jeans pocket*

*launches the middle finger on that hand*

Matt:  “Boom!”

*5 second silence while I stare at him with a completely unimpressed facial expression*

*5 more seconds*

*5 more seconds*

He doesn’t say a word and just walks off.  For the following three weeks he never said a word to my face despite being my project manager and walking by my desk multiple times every day.  For my part, I never attempted to initiate any kind of a conversation as I had zero desire to ever speak to him again.  I left the contract job within the month.

I never disclosed this information to HR at the company because I knew I would be leaving as soon as possible, should I have done so?  How would you have handled the situation?


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.


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.


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.


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


<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:



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:


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.



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