Category Archives : Programming

This category is designed for entries which relate to software development


CRM Reporting Extensions – SSRS not listed

Just a quick entry in case you are trying to solve a problem when attempting to install CRM Reporting Extensions.  You might encounter a situation where you specify the SQL Server machine or instance name, but proceeding to select the SSRS instance produces a blank list. 

So you need to install Reporting Extensions AFTER you’ve successfully installed Dynamics CRM.  Partially this is so that the Organisation and associated reports (if any) are correctly published to SSRS.  Aside from this, also verify the following…

First thing to check is that you’re installing the Reporting Extensions on the SSRS/SQL location and NOT the CRM Application server(s).

If so far everything is correct, check the log file for the installer.  You can specify a location other than the default, invoke the installer from a command prompt like this:

image

SetupSrsDataConnector /Q /CONFIG c:\temp\install-config.xml /L c:\temp\log.txt

If you find the following in the installer log:

  • “Could not find a local RS instance corresponding to the reporting url http:///<reportserver> for organization <org name>”
  • “Organization <org name> does not have reports published”

It could be that you’re trying to install against a 32 bit version of SQL Server, or an unsupported edition (see supported editions and how to check your edition of SQL Server in the References, below).

You can also use the command line to specify a configuration file, here’s an example:

<crmsetup>
  <srsdataconnector>
    <configdbserver></configdbserver>
    <autoupdateconfigdb>1</autoupdateconfigdb>
    <reportserverurl>
http://servername/Reportserver</reportserverurl>
    <autogroupmanagementoff>0</autogroupmanagementoff>
    <instancename>Titan</instancename>
    <configsku>OnPremise</configsku>
    <!– Set enabled = true for DB webstore integration.  Set configdb=”true” for config db webstore integration–>
    <webstore enabled=”false” configdb=”false” />
    <monitoring>
<!– Monitoring service account name and password. It can not be local system or network service account –>
      <serviceaccountname></serviceaccountname>
      <serviceaccountpassword></serviceaccountpassword>
    </monitoring>
  </srsdataconnector>
</crmsetup>

References

Microsoft Dynamics CRM reporting requirements – https://technet.microsoft.com/en-us/library/hh699754.aspx

How to determine the version, edition and update level of SQL Server and its components – https://support.microsoft.com/en-au/kb/321185

Install Microsoft Dynamics CRM Reporting Extensions using a command prompt – https://technet.microsoft.com/en-us/library/hh699725.aspx


Manage ServicePrincipalName Properties Using PowerShell

A few years ago [1] I wrote about how you could enable Domain Accounts to self-manage their ServicePrincipalNames.  This is particularly advantageous when using Kerberos to secure services.

We recently needed to set up some service accounts in Active Directory to participate in establishing a Kerberos capability for middleware integration.  I began unpacking the ADSIEdit approach, but stopped.  Whilst you can reach your end goal using the “established” approaches, it’s an absolute pain to deploy these changes to other environments.  Surely there must be a better way?

Enter PowerShell.  We can automate (by scripting) the ability to grant Active Directory accounts the ability to read and write ServicePrincipalName.  Eureka!  Full credit goes to this excellent answer on StackOverflow [2].

   1: Function Set-SpnPermission {

   2:     param(

   3:         [adsi]$TargetObject,

   4:         [Security.Principal.IdentityReference]$Identity,

   5:         [switch]$Write,

   6:         [switch]$Read

   7:     )

   8:     if(!$write -and !$read){

   9:         throw "Missing either -read or -write"

  10:     }

  11:     $rootDSE = [adsi]"LDAP://RootDSE"

  12:     $schemaDN = $rootDSE.psbase.properties["schemaNamingContext"][0]

  13:     $spnDN = "LDAP://CN=Service-Principal-Name,$schemaDN"

  14:     $spnEntry = [adsi]$spnDN

  15:     $guidArg=@("")

  16:     $guidArg[0]=$spnEntry.psbase.Properties["schemaIDGUID"][0]

  17:     $spnSecGuid = new-object GUID $guidArg

  18:  

  19:     if($read ){$adRight=[DirectoryServices.ActiveDirectoryRights]"ReadProperty" }

  20:     if($write){$adRight=[DirectoryServices.ActiveDirectoryRights]"WriteProperty"}

  21:     if($write -and $read){$adRight=[DirectoryServices.ActiveDirectoryRights]"readproperty,writeproperty"}

  22:     $accessRuleArgs = $identity,$adRight,"Allow",$spnSecGuid,"None"

  23:     $spnAce = new-object DirectoryServices.ActiveDirectoryAccessRule $accessRuleArgs

  24:     $TargetObject.psbase.ObjectSecurity.AddAccessRule($spnAce)

  25:     $TargetObject.psbase.CommitChanges()    

  26:     return $spnAce

  27: }

Now, you’d invoke this function this way:

   1: $TargetObject = "LDAP://CN=svc_account,OU=Service Accounts,DC=Development,DC=sanderstechnology,DC=com"

   2: $Identity = [security.principal.ntaccount]"DEVELOPMENT\svc_account" 

   3: Set-SpnPermission -TargetObject $TargetObject -Identity $Identity -write -read

Voila!

[1] http://sanderstechnology.com/2010/some-handy-articles-on-configuring-kerberos-with-service-principal-names-spns/9987/
[2] http://stackoverflow.com/questions/4156743/powershell-how-do-you-set-the-read-write-service-principal-name-ad-permissions