A WordPress.com site dedicated to System Center and Cloud Management

Archive for March, 2014

Service Manager 2012 R2 Installation Fails To Identify SQL Server Instance, and Throws ‘Access Denied’ Error

I came across this error/issue when attempting to install System Center Service Manager in my lab. My architecture/design is to have 3 servers:

  1. One for the Service Manager Management Server along with its database
  2. One for the Service Manager Warehouse along with its database and SQL Reporting Services, and SQL Analysis Services
  3. One for SharePoint for the Self-Service Portal

So lets start with my Virtual Machine configuration.  For each of the VMs, I have given it a maximum of 8GB of RAM, along with 4 virtual CPUs.

SCSM VM Settings

For the Service Manager Management Server, since I will its database locally, I installed SQL Server 2012 SP1 with the following features; namely: Database Engine Services, Full-Text and Semantic Extraction for Search, and the complete Management Tools.

SCSM-MS SQL Server Configuration

Note the SQL Server Instance name that I used (in this example SCSMMSSQLSERVER). Generally, since I monitor my environment with Operations Manager (SCOM), I don’t like to use the default naming for SQL Instances, especially when I install SQL Server locally for each System Center product. This means that, if I were to use the default SQL instance naming (MSSQLSERVER), I would end up with a lot of instances labelled the same thing in the Operations Manager (SCOM) console. this doesn’t make it easy to identify which instance is potentially having an issue.

So generally, I like to use the product name and append “SQLSERVER”. For example, the SQL Server Instance name for SCOM would be “SCOM” + “SQLSERVER” = “SCOMSQLSERVER”. In the case of Service Manager, there are 2 SQL Instances that are used, one for the Service Manager database, and another for the Service Manager warehouse database. Therefore, I wouldn’t just name each instance “SCSM” + “SQLSERVER”, as that would cause a duplicate instance name (see the paragraph above about my ramblings for unique naming). So, logically I need to add something else to the SQL Server Instance name to identify between the Service Manager Management Server, and the Warehouse Server. Hence the “SCSM” + “MS” (Management Server) + “SQLSERVER”. I followed this same naming convention for the Warehouse SQL Server Instance (i.e. “SCSM” + “WH” + “SQLSERVER”).

OK, enough of the back-story. When I attempted to install System Center Service Manager – Management Server, in particular on the “Configure the Service Manager database” screen, I encountered the following error: “Access to the SQL Server instance <Server Name\Instance Name> was denied.”

SCSM-MS Configure Service Manager Database Error 01

I even attempted to use the Full Qualified Domain Name (FQDN) for the server name, but the same error occurs.

SCSM-MS Configure Service Manager Database Error 02

Of interesting note is SQL Server instance that is “discovered”. It’s odd that it says “SCSMDefault”, because if you look at my SQL Server installation, that’s not the instance name.

SCSM-MS SQL Server Name and Instance

That doesn’t make any sense. Why would the installation wizard, when given the correct server name, be unable to discover the correct (and in this case, only) instance configured on the server? Additionally, it gives an error about access being denied; although I know for certain that I am using an Administrator account (which has been configured with Local Admin on the server, and SysAdmin on the SQL Server installation).

I spent countless days searching the web for any articles on System Center Service Manager, database requirements, and the specific error that was generated; all to no avail. I read articles that mention things such as: firewalls, SQL Named Pipes, SQL TCP/IP, Dynamic Ports vs. Static Ports, SQL Allow Updates, using underscores in database names, SQL remote connections, etc. All of these did not resolve the issue. I even tried installing SQL Reporting Services and SQL Analysis Services (since the documentation isn’t specifically clear which database; either the Service Manager database, or the Data Warehouse database). And yet I still encountered the error.

What made matters even more confusing and difficult to troubleshoot, was the fact that the installation for the Data Warehouse (using the same naming convention, and in fact had the same number of characters in the SQL Server instance name), did not show the same error!

SCSM-WH Configure Data Warehouse Databases

SCSM-WH Configure Data Warehouse Datamarts

Then I came across this article (http://stackoverflow.com/questions/5260650/max-length-of-sql-server-instance-name) that mentioned a limitation to the Instance Name length. However, the article referenced a different version of SQL Server than I was using. Note: I am using SQL Server 2012 SP1. So, I tried finding “SQL Server Books Online” for SQL Server 2012, and although it does exist (found here: http://technet.microsoft.com/en-us/library/ms130214.aspx), I could find any information on Instance Naming Configuration. So, based on reference to older versions of SQL Server (see http://msdn.microsoft.com/en-us/library/ms143531(v=sql.120).aspx), “Instance names are limited to 16 characters”.

So armed with this information, I went back and reviewed my Instance Name. Hmmm, “S-C-S-M-M-S-S-Q-L-S-E-R-V-E-R” is only 15 characters, so it “fits”, so what gives? Well, not being a Database Administrator (DBA), I don’t really know. I figure that the Server Name might somehow tie in with length restrictions/SQL references.

So, I decided to uninstall/re-install SQL Server on the Service Manager Management Server with a shorter SQL Server Instance Name. This time, instead of “SCSMMSSQLSERVER”, I used “SCSMMS”. Then I re-ran the System Center Service Manager Management Server installation. When I got to the “Configure the Service Manager database” screen, the installation wizard was able to successfully connect to the SQL Server (even though it IS on the LocalHost), and this time it was able to correctly identify and access the SQL Server Instance!

SCSM-MS Configure Service Manager Database Error Corrected

I’m still not 100% sure why this is, and I have not been able to find any official documentation from Microsoft (either in relation to SQL Server 2012 SP1 or System Center Service Manager 2012 R2). But hopefully my experience (and potential resolution, or at least work-around), will be of some help to someone else.

Configuring SCORCH Integration Pack Connection(s) Produces A “Blank” Error

Hi everyone, I came across this issue while recording some videos to go along with the articles I have written/posted (NOTE: MiCloud now has its own YouTube channel!).

So, in System Center Orchestrator, after you have downloaded, installed, registered, and deployed Integration Packs, you need to setup/configure the connection between Orchestrator and the product. In this case, I was demonstrating with the System Center Operations Manager Integration Pack. When I attempted to configure the connection to the SCOM server, and tested the connection, Orchestrator threw an error. No big deal right? Wrong! The error was blank/empty! Even checking the Event Logs didn’t provide any help.

SCORCH Connection Blank Error

So what is the solution? Well, I never did find any log files or event logs, etc. that could help point me in the right direction. However, I remembered that when using Orchestrator (and integrating with other systems) you need the application’s console installed. So in this case, since I was working with the SCOM Integration Pack, I had to install the SCOM Console (and connect that console to the SCOM Management Server).

I won’t walk through how to install the SCOM console (you can see how through my SCOM Installation Guide). After I completed the SCOM console installation and connected it to the Management Server, I went back into the Orchestrator Runbook Designer and attempted to create the connection. This time I was able to successfully test the connection.

SCORCH Connection Successful

So, the lesson is, when working with Orchestrator and Integration Packs, always remember to install the console for the System Center product you are working with. If only Microsoft would include useful information in Error messages 😉

Windows Server 2012 R2 Generation 2 VMs and x86 MDT Boot Media = Boot Failure!

I came across this scenario today, when creating a video walk through on using the Microsoft Deployment Toolkit (MDT) 2013, which can be found on my MiCloud YouTube channel: http://www.youtube.com/user/SCMiCloud.

When using the Microsoft Deployment Toolkit (MDT) to build and capture a reference image, part of the process is to create Boot Media. To use MDT to build and capture an image, you need to mount the boot media ISO to your Virtual Machine (VM).

Normally, when creating and using boot images (with MDT or SCCM), I usually use the x86 version of the media and not the x64. Why, you might ask? This is because x86 is more versatile and more widely compatible than x64 media. 

However, in Windows Server 2012 R2, when you create a new Virtual Machine, you can choose a Generation for the VM.

VM Generation

In my case, I was trying to build and capture a Windows 8.1 reference image. Therefore, I choose the Generation 2 option. Note that it states: “Guest operating systems must be running at least Windows Server 2012 or 64-bit versions of Windows 8”. Therefore, you would think that you could use x64 bit boot media with these systems.

So, as stated above about x86 versus x64 boot images, I mounted the x86 version of the MDT Boot Media, and started the Virtual Machine, preparing to build and capture an image. Except, no deal! Boot Failed! Weird.

VM Boot Fail

After trying many different things, including re-creating the VM, changing the network adapter (from current to legacy), re-generating the Boot Media, etc.

Then, for reasons I cannot recall, I decided to try the other Boot Media. I mounted the x64 version of the Boot Media, restarted the VM, and bam! The MDT boot media started to load without issue.


I am not 100% sure why this is, but apparently if you are using Hyper-V, and in particular a ‘Generation 2’ Virtual Machine for building and capturing a reference image (either through MDT or SCCM), you will need to use 164-bit Boot Media instead of the x86.

Hope this helps someone if they encounter this issue.

Tag Cloud

%d bloggers like this: