FIM 2010 R2 SP1: Reporting and Auditing Services with System Centre Service Manager 2010 SP1 "The SSRS Web Services URL is not valid." and SQL Reporting Service "The report server installation is not initialized (rsReportServerNotActivated)

I have been building out a full Forefront Identity Manager 2010 R2 SP1 solution including the optional component of Reporting and Auditing Services. The components of Reporting and Auditing Services for FIM 2010 R2 SP1 are System Centre Service Manager 2010 (SCSM 2010) and SQL Server Reporting Services. I was in the middle of installing the System Centre Service Manager Data warehouse component of SCSM 2010 and the installation was stopped when I was asked to "Configure the Reporting Server for the Data Warehouse", I pointed to the SQL Reporting Service Server and it returned the error "The SSRS Web Services URL is not valid." this stopped me from continuing.

 

 

For testing I tried to open one of the preconfigure Reporting Services websites, when I did this the website was not operational with the error SQL Reporting Service "The report server installation is not initialized (rsReportServerNotActivated).

 

The solution in this case was to click on the Encryption Keys page and under Delete Encryption Content us the delete key to remove the encryption files.

 

 

You will be asked to confirm you want to delete the encrypted content.

 

After doing that I returned to the website and did a refresh the website was then functioning. When I returned to the Server Manager interface and refreshed that, the error was also resolved and I could continue with the install.

Forefront Identity Manager 2010 R2 SP1 (FIM): Connection to SQL Server 2008 R2 for FIM Sync Service "Connection Failed: SQL State: '08001' SQL Server Error: 5 Could Not open a Connection to SQL Server [5]. Connection Failed: SQLState: 'HYT00' SQL Server Error: 0 [Microsoft][SQL Server Native Client 10.0]Login Timeout Expired"

Recently I have been building a FIM 2010 R2 SP1 Sync Service Server using an external SQL instance running on SQL Server 2008 R2. When I was creating the ODBC Data Source using the SQL Server Native Client 10.0 I receieved the following error "Connection Failed: SQL State: '08001' SQL Server Error: 5 Could Not open a Connection to SQL Server [5]. Connection Failed: SQLState: 'HYT00' SQL Server Error: 0 [Microsoft][SQL Server Native Client 10.0]Login Timeout Expired".

 

 

The solution here was to enable TCP/IP from the SQL Server Configuration Manager to do this launch the SQL Server Configuration Manager MMC expand SQL Server Network Configuration and click Protocols for MSSQLSERVER right click and select Properties on the TCP/IP protocol. From the Properties window click IP Addresses using the Active drop downs select Yes for IP1 and IP2. Click OK.

 

For the changes to apply you must restart the SQL instance to do this click on SQL Server Services from the left hand list, right click SQL Server (MSSQLSERVER) and select Restart.

 

To finish off open the SQL Management Studio and login using Windows Authentication.

 

Right click on the top (local) database icon and select Properties.

 

Click on the Security tab and change the Server Authentication to SQL Server and Windows Authentication Mode. Click OK.

 

Again the SQL Server must be restarted. In this instance I rebooted the entire server.

 

Once this has been done you can continue with the ODBC Data Source Connector.

Active Directory "Changing the Primary Domain DNS name of this computer to "" failed. The name will remain "name.domain". The error was: No mapping between account names and security ID's was done. when attempting to add Windows Server 2008 R2 Server to Domain. C:\Windows\Debug\NetSetup "NetpSetDnsHostNameAndSpn: NetpGetcomputerObjectDn Failed: 0x534"

After some rebuilding of lab VM's you have recreated a VM, assigned an IP and are now trying to re-join the domain. You are attempting to use the same hostname as the VM had previously, the old Computer Objects have been deleted from Active Directory. When you try to join the domain you receive the error "Changing the Primary Domain DNS name of this computer to "" failed. The name will remain "name.domain". The error was: No mapping between account names and security ID's was done. "

 

To look further into this issue I opened up the C:\Windows\Debug\NetSetup log file and it stated "NetpSetDnsHostNameAndSpn: NetpGetcomputerObjectDn Failed: 0x534".
 

 

After some research there was loads of blogs stating the error "NetpSetDnsHostNameAndSpn: NetpGetcomputerObjectDn Failed: 0x534" could be resolved by disabling NetBIOS etc, I was not convinced as it was functioning correctly the day before. To check on the health of the domain I used the command dcdiag /a from one of the Domain Controllers.

The dcdiag /a returned the following errors

"0x0000165B The session setup from computer "blank hostname" failed because the security database does not contain a trust account "blank hostname" referenced by the specified computer."

"0x000016AD The session setup from the computer "blank hostname" failed to authenticate."

 

The issue in this case was down to my own patience, I had deleted the old computer objects on one of the Domain Controllers. As the replication topology was configured to replicate every 15 minutes the other DC's in the domain had not received the directory changes.

The quick fix was to force and Active Directory replication from the Active Directory Sites and Services MMC.

 

When I tried to add another VM to the domain it worked without issue and the computer object appeared under the default Computers OU as expected.

Forefront Identity Manager (FIM) Synchronization Service Evaluation is having trouble contacting SQL server using the provided information. Please note that Forefront Identity Manager Synchronization requires Microsoft SQL Server 2008 SP1 or better. Verify the version, server and instance names as well as firewall.

When you try to install the Forefront Identity Manager (FIM) 2010 R2 SP1 Synchronization Service to use an off-box SQL Server instance you receive the following error "Forefront Identity Manager Synchronization Service Evaluation is having trouble contacting SQL server using the provided information. Please note that Forefront Identity Manager Synchronization requires Microsoft SQL Server 2008 SP1 or better. Verify the version, server and instance names as well as firewall."

 

 

In this particular instance FIM 2010 R2 SP1 is running on Windows Server 2008 R2 and the SQL Server is Windows Server 2012 R2 with SQL 2012 Standard. As with all off-box SQL instance I had created a ODBC (64-bit) from the FIM server, to the SQL. When I tested connectivity it all came back as working.

As part of the troubleshooting I tried the following things without success

·      Connectivity and Name Resolution

o     Ping and Nslookup

·      SQL Services

o     Ensured SQL Server Browser and SQL Server Agent were set to Automatic and Running

·      Disabled the SQL Server Firewall

o     To rule out any issues with port 1433, then tried Telnet all OK

Although all of these tests came back positive the issue was not resolved. The issue was with the SQL ODBC connection from FIM to SQL. I had created the ODBC using the standard SQL Server Client build into Windows Server 2008 R2.

The fix was to install the SQL Server 2012 Native Client, which can be downloaded from Microsoft http://microsoft.com/en-gb/download/confirmation.aspx?id=29065

 

Once I recreated the ODBC connection with the SQL Server 2012 Native Client the setup then allowed me to continue, the next step was to configure the FIM security groups.

Windows Server 2012 R2: Enabling the Active Directory Recycle Bin from the Active Directory Administrative Center "The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner."

Windows Server 2012 R2: Enabling the Active Directory Recycle Bin from the Active Directory Administrative Center "The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner." prevents you from enabling the Active Directory Recycle Bin.

 

 

From an Administrative Command Prompt I used the following command to confirm the FSMO role holders.

netdom query fsmo

Everything looked normal here so I continued to the next step which was to run the Active Directory Best Practice Analyser from Server Manager.

 

The Active Directory BPA came back with the error "The primary domain controller (PDC) emulator specification master in this forest is not configured to correctly synchronize time from a valid time source".

I used the following command from an Administrative CMD to configure the PDC Emulator to use time.microsoft.com as it's authoritive time source.

w32tm /config /manualpeerlist:time.microsoft.com /syncfromflags:manual /reliable:yes /update

 

 

I then issued this command on all of the other Domain Controllers to ensure they reflected the changes.

w32tm /config /syncfromflags:domhier /update

 

After this I re-run the Active Directory Best Practice Analyser and the error had been resolved.

 

I could then continue and enable the Active Directory Recycle Bin.

Connecting to Office365 using PowerShell for Remote Management

You can using PowerShell from an on-premise server to manage an instance of Office365 in Microsoft's cloud. It can be useful to manage more of the complex Exchange, Lync and SharePoint configuration settings that are available.

Firstly open an Administrative PowerShell box, I did this from Windows Server 2012 R2 copy and paste the following command into the PowerShell window.

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://ps.outlook.com/powershell/" -Credential $cred -Authentication Basic -AllowRedirection

This will invoke a credentials window that you must enter the Global Administrator account for the Office365 subscription. It should be in the format username@domain with the corresponding password.

The next command is the following to create a new session;

Import-PSSession $session

Once this command has completed you can use the following two PowerShell commands to create to see what commands are available in the Office365 PowerShell module that has been imported.

Get-Module ModuleName

Get-Command –Module ModuleName

To confirm it is working I did a Get-Mailbox and PowerShell returned a list of all of the Office365 mailboxes active on the subscription. 

Configuring DirSync for Syncrhonization Between Azure Active Directory and Traditional On-Premise Active Directory

The purpose of the Azure Active Directory DirSync tool is to allow your on-premise users the ability to take advantage of Single Sign On (SSO) when using cloud-based applications in Microsoft Azure. Microsoft Azure Active Directory is different from a traditional Active Directory as it is a service offered by Microsoft.

Do not confuse Azure Active Directory with having Domain Controller VM's running in Azure that are configured to replicate between your on-premise domain. Azure AD is a managed cloud service from Microsoft.

The first step is to download and install the Azure Active Directory DirSync tool from the Technet website the following link will take you to the correct place http://technet.microsoft.com/en-us/library/jj151800.aspx, please note that the DirSync tool should be installed on a member server within the on-premise Active Directory and not a Domain Controller.

The installation is straight forward, click Next.

Accept the EULA and click Next.

Choose an installation folder and click Next.

The installation can take up to 10 minutes to complete.

While the DirSync tool is being installed return to the Azure Management Console and click Active Directory and then double click on the Azure Active Directory you want to configure the DirSync.

Click Users and then Add to create a new users within the Azure Active Directory.

Configure this user with a username and use the arrow button to continue.

Populate the user profile fields with the corresponding information, the import part here is that the Role must be set to Global Administrator this is required to configure DirSync.

The wizard will output a temporary password that will need to be reset.

Take note of the tempoary password as you will need it to reset the password before the account will work with DirSync.

Go over to the Azure Active Directory login website and use the e-mail address and temporary password to login. 

You will be prompted to reset the tempoary password, if you miss this step the Global Administrator account you configured will not work with the DirSync tool.

The next step is to ensure that Integration with Local Active Directory is activated on the Azure AD instance you can do this by going to the Properties of the Azure AD and selecting the Director Integration tab. From here select the Active button and ensure you Save the changes.

Accept the prompt about the impact of enabling activation by clicking the arrow.

The next step is to configure the Azure Active Directory DirSync tool, by default this will launch after it completes installation on the member server. 

Click Next.

Now you must specify that Global Administrator account that was created previously, click Next to continue.

You will next be prompted for an Active Directory Enterprise Administrator credential set, this is for the on-premise Active Directory. Click Next.

At this stage I have not enabled the Hybrid Deployment, click Next.

Ensure the Password Sync box is ticked and click Next.

The DirSync tool will configure all the required components.

On completion you will be asked if you want to perform the first directory sync, by default this happens every 3 hours.

To ensure the DirSync tool is working correctly return to the Azure Active Directory screen and click on Users this should then be populated with all the users you currently have in the on-premise domain.