I recently migrated a customer from a 3 server SCSM topology to a 5 server SCSM topology and I am now having an issue registering the Data Warehouse Management Server with the Service Manager Management Server.
All servers run Windows Server 2012 except for SCSM3, which run 2008 R2 SP1.
Name: Data Access Service SPN Not Registered Description: The System Center Data Access service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/hostname and MSOMSdkSvc/hostname.domain.name to the servicePrincipalName of CN=hostname,OU=MyOU,DC=domain,DC=name.
Original Configuration
SCSM1
- Service Manager Management Server 2012 SP1 UR2
- SQL Server 2012 with ServiceManager and SharePoint Foundation 2010 (for SSP) databases
SCSM2
- Service Manager Data Warehouse Management Server 2012 SP1 UR2
- SQL Server 2012 with all 5 data warehouse databases on it, as well as SSRS and SSAS.
SCSM3
- SharePoint Foundation 2010 SP1
- Service Manager 2012 SP1 UR2 Web Content Server
- Service Manager 2012 SP1 UR2 SharePoint Web Parts
Revised Configuration
SCSM1
- Service Manager Management Server 2012 SP1 UR2
SCSM2
- Service Manager Data Warehouse Management Server 2012 SP1 (You cannot install UR2 until the DW has been registered an MPSync has run successfully multiple times)
SCSM3
- SharePoint Foundation 2010 SP2
- Service Manager 2012 SP1 UR2 Web Content Server
- Service Manager 2012 SP1 UR2 SharePoint Web Parts
SCSM4
- SQL Server 2012 with ServiceManager and SharePoint Foundation 2010 (for SSP) databases
SCSM5
- SQL Server 2012 with all 5 data warehouse databases on it, as well as SSRS and SSAS. SSRS was configured with the proper manual configuration detailed here - http://technet.microsoft.com/en-us/library/hh519664.aspx
Migration Steps
The customer was hitting performance issues which are common when SQL is located on a management server, so I did the following:
- Stand up two new servers that will function as dedicated SQL Servers.
- Unregister the Data Warehouse (the install was relatively new, so no DW data retention was necessary)
- Uninstall SharePoint Foundation and the WCS from SCSM3
- Uninstall SQL Server from SCSM1
- Uninstall the Data Warehouse Management Server from SCSM2
- Uninstall SQL Server from SCSM2
- Reinstall the Self-Service Portal on SCSM3 using the new database server for SharePoint databases.
- Reinstall the Data Warehouse Management Server on SCSM2 specifying the new database server during the install. I've tried this using both the old DW Management Group's name and a new Management Group name.
This all went fine (including the Data Warehouse installation), but when I go to register the new Data Warehouse with the Service Manager Management Server, I get the following error:
The Data Access Service is either not running or not yet initialized
A similar error is thrown when trying to register the DW via PowerShell using
Register-SCDWSource
The service (and all other System Center Services) are indeed running on all servers that they should be running on. Service Manager itself is working fine after the database migration. The Self-Service Portal is functioning properly as well.
There are no rows in the
dbo.MT_Microsoft$SystemCenter$ResourceAccessLayer$DwSdkResourceStore
table, as the old Data Warehouse was successfully unregistered, so truncating this table won't resolve the issue.What I've tried based on TechNet article and forum posts:
- Restart System Center services on all servers.
- Verify that my account in in the Built-InAdministrators group on all servers.
- Verified that my account is in the Service Manager administrators group.
- Verified that the proper SPNs for the Data Access Service are registered manually.
- Disabled anti-virus temporarily on each server.
- Telnet to port 5724 works between all servers and workstations in the environment.
Does anyone know what else could be causing this?
MDMarraMDMarra93.3k2828 gold badges177177 silver badges314314 bronze badges
1 Answer
This is an old posting, but it's a situation I found myself in recently under the same circumstances. The problem I had was self-inflicted, when you go through the process of updating all the SCSM DB table references to the old servers and point them to the new servers, all of them point to the new SQL server except the dbo. MT_Microsoft$SystemCenter$ResourceAccessLayer$SdkResourceStore which points to the primary management server. I accidentally set that to the new SQL server, hence the DW registration error about the data access service not running. Once I found and fixed the problem, DW registration worked.
StuartStuart
Not the answer you're looking for? Browse other questions tagged windowssystem-centerscsm-2012 or ask your own question.
Applicable Products
- Citrix Virtual Desktops
- XenDesktop
Information
Citrix Virtual Apps and Desktops, formerly XenDesktop, fits the enterprise need to bring both VDI and apps into a user-centric experience.
This article contains information about Troubleshooting Virtual Delivery Agent Registration with Controllers in XenDesktop.
Background
XenDesktop relies upon a software component installed on each virtual desktop (the Virtual Delivery Agent) being in communication with one of the controllers in your XenDesktop site. This state is referred to as the VDA being registered with a controller. If communication fails for any reason, the VDA is said to have failed to register with a controller. It is then not possible for XenDesktop to broker a connection to the virtual desktop in question, and the virtual desktop becomes a wasted resource.The VDA logs problems with registration in its event log, as shown in the following example: A custom view can be created by selecting Citrix Desktop Service and Citrix ICA service as Source. Alternatively, these events can be found in Application event long.
The details of the four most recent event log entries are:
Level | Date and Time | Source | Event ID | |
---|---|---|---|---|
Warning | 12/8/2010 10:03:59 AM | Citrix Desktop Service | 1022 | 'The Citrix Desktop Service failed to register with any controllers in the last 2 minutes. The service now tries to register with controllers at a reduced rate of every 2 minutes.' |
Warning | 12/8/2010 10:01:55 AM | Citrix Desktop Service | 1017 | 'The Citrix Desktop Service failed to register with any delivery controller. The service retries registering with controllers in approximately 8 seconds. Please ensure that at least one delivery controller is available for Virtual Desktop Agents to register with. Refer CTX117248 for further information.' |
Warning | 12/8/2010 10:01:55 AM | Citrix Desktop Service | 1002 | 'The Citrix Desktop Service cannot connect to the delivery controller 'http://DDCXD501.demo.net:80/Citrix/CdsController/IRegistrar' (IP Address '10.10.220.10') Check that the system clock is in sync between this machine and the delivery controller. If this does not resolve the problem, refer to CTX117248 for further information. Error Details: Exception 'An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.' of type 'System.ServiceModel.Security.MessageSecurityException'..' |
Information | 12/8/2010 10:01:55 AM | Citrix Desktop Service | 1010 | The Citrix Desktop Service successfully obtained the following list of 1 delivery controller(s) with which to register: 'DDCXD501.demo.net (10.10.220.10)'. |
If the virtual desktop in question has been added to a desktop group in your XenDesktop site, you will also see evidence of the VDA's failure to register with any controllers in the site, in the administration consoles. The following screen shot shows how this looks in Citrix Director.
Here, the State column provides information about the registration state of the desktop machine. A value of UnRegistered indicates that registration has not successfully completed.
Troubleshooting Registration Problems
Virtual Desktop not Added to the Correct Site
If you see VDA event log entries on the worker suggesting registration failure, complete the following steps:- Check that the virtual desktop is correctly added to the correct XenDesktop site. This must be done from both the point of view of the virtual desktop and of the XenDesktop site itself.
- In Desktop Director, enter the name of the machine into the search box – the machine name must appear in the drop-down that appears below the search box as you type the name. If it does not, it means that the machine has not been added to the site correctly.
- Check that the machine in question is a member of the correct site, check that the list of controllers listed in the event log entry with Event ID = 1010 on the virtual desktop is correct for your XenDesktop site. If it does not, the virtual desktop has not been correctly configured to be part of the site.
Virtual Desktop Firewall not Properly Configured
If the firewall on the virtual desktop has not had the appropriate exclusions configured to enable communication with controllers, the registration fails. As an experiment, try disabling all firewall software on the virtual desktop and restart it. If registration now succeeds, the problem points to misconfiguration of the firewall; reconfigure it and re-enable it.Note: It is not advisable to run with the firewall permanently disabled on virtual desktops.
Domain Name Services (DNS) not Properly Configured
If the virtual desktop or the controller sees an incorrect IP address for the other party, registration fails. To see if this is an issue, try the following: on both machines, start a command shell window and run the following commands: Both machines must be able to ping each other successfully with DNS name (using the fully qualified domain name (FQDN) including the domain.com bit and not the simple NetBIOS name). It is important that, the IP address reported for the remote machine using the ping command in each case must match the IP address reported using ipconfig command on the relevant machine.If there is any discrepancy, fix the problem with your DNS configuration and restart the virtual desktop, the controller, or both, as appropriate.
Time Synchronization not Properly Configured
The communication between virtual desktops and controllers is secured using Kerberos. This relies on Tickets with a limited life span. If the difference in system time between the two ends of the communication is too great, the Tickets are always considered to have timed out when they are accessed and communication fails.Check that the system time on all systems is within a reasonably small margin (the default domain-wide Kerberos setting is five minutes).
Note: Check the Windows Time Service is running on the VDA, if the service is in stopped state, try starting the service and check if this has fixed the Time Sync issue and VDA is registered now.
If this is the issue, for pooled random catalog correct the Windows Time Service on the master image and update the VDAs.
Domain Membership Problems
Under some circumstances, it can appear that a machine (virtual desktop or controller) is a part of a domain, but in fact, it is not (for various reasons). This can cause problems with the secure communication between virtual desktops and controller.Try removing the machines in question from their domains (temporarily moving them into a workgroup, for example) and then subsequently rejoin them to their domains. When the subsequent system restart has completed, check to see if registration has been successful.
Service Principal Names (SPNs)
Communication between virtual desktops and controllers uses Microsoft’s Windows Communication Foundation (WCF). The services implementing the communication endpoints use the computer’s identity. Thus, WCF’s mutual authentication model uses the SPN associated with the respective computer accounts (by default, HOST/host’s-fully-qualified-domain-name). The controller determines the virtual desktop’s SPN after inspecting the servicePrincipalName attribute of the associated computer account in Active Directory.You can inspect the virtual desktop’s computer account using tools such as Active Directory Explorer. If the servicePrincipalName attribute does not include an entry with the computer’s fully qualified domain name, try editing it manually, and check to see if that fixes registration problems.
Multiple Network Adapters
If your virtual desktops contain multiple network adapters that can be used to communicate with the controllers, this might cause the security negotiation to fail. In that case, try disabling all network adapters except for the one used to communicate with the controllers.'Access this computer from the network' rights
By default, this should work, but if your environment is more secured, you can run into an issue when controller is not able to access VDA. This behavior is described in CTX117449.
The Flowchart here will help you to troubleshoot VDA registration:
If the above approach does not help, you may download the Citrix Health Assistant utility and run it on the VDA which is not registering from CTX207624 - Citrix Health Assistant - Troubleshoot VDA Registration.Additional Resources:
Citrix Blog - XenDesktop Brokering Process, Knowledge Center Highlights: App Virtualization & VDI (July Edition)
XenDesktop Registration Failure when Microsoft Global Catalog Port 3268 is Blocked
VDA's do not register with XenDesktop controllers when there is NAT in place between VDA and DDC
VDA's do not register with XenDesktop controllers when there is NAT in place between VDA and DDC