Tuesday 30 August 2011

FIX - SharePoint 2010 - Disabled New, Extend and Delete Buttons for Web Applications in Central Administration

My current client (a large NSW Government Department) has a test environment that doesn't have Active Directory and they required Duet Enterprise to be installed. After a basic install of SharePoint 2010 with SP1- in Windows Server 2008 R2, SQL 2008 R2, I was alarmed to find that I couldn't create new web applications via Central Administration. When I hovered over the buttons, it said that this functionality is disabled due to insufficient permissions:


I also couldn't add users to the farm administrators account - I would get an odd exception - "Local administrator privilege is required to update the Farm Administrators' group."

I tried rebooting, uninstalling, reinstalling to no avail - the same problem persisted.
There are many recommended fixes for this problem - most of which didn't work for me:
  1. Run in an alternative browser such as Google Chrome/Firefox - this didn't work for me.
  2. Ensure that the Application Pool account in IIS has the correct database permissions - this wasn't the problem in my situation as the user was a full local administrator and sysadmin on the database
  3. Ensure that you run IE as an administrator - this is already done by the default shortcut to the SharePoint Central Admin (I wasn't opening up SharePoint Central Admin from a seperately instantiated browser - so this also wasn't the problem)
  4. Ensure that UAC is turned off as this somehow interferes with the application of security to those controls. Most references to this indicated that this worked for Windows 7, but there was no reference to this working for Windows Server products.
To my surprise, number 4 was the one that worked for me. To do this (in Windows Server 2008+), you have to go to:
Control Panel - User Accounts - Turn User Account Control On or Off

After the reboot, the controls were suddenly re-enabled. This is not a recommended configuration - but this was purely for demonstration purposes rather than being a production-ready install (we would be using Active Directory for that anyway).

DDK






Friday 26 August 2011

SQL Server 2008 R2 Master Data Services (MDS) IWorkflowTypeExtender - Implementation and Debugging

SQL 2008 R2 Master Data Services (MDS) has a basic plugin framework which allows you to handle events when business rule workflows are kicked off. You implement your custom plugins by:
1) Creating a class that implements IWorkflowTypeExtender. This is contained in the following assembly:
C:\Program Files\Microsoft SQL Server\Master Data Services\WebApplication\bin\Microsoft.MasterDataServices.Core.dll

2) Build and deploy the file to the bin directory (typically "C:\Program Files\Microsoft SQL Server\Master Data Services\WebApplication\bin") or a subdirectory of it if you use a PrivatePath (discussed below).
3) Modify the "Microsoft.MasterDataServices.Workflow.exe.config" file to point to your new assembly:

<configuration>
  <configsections>
    <section name="loggingConfiguration" requirepermission="true" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
    <sectiongroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="Microsoft.MasterDataServices.Workflow.Properties.Settings" requirepermission="false" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    </sectiongroup>
  </configsections>


4) Add another section to your config file that indicates what workflows to listen to (based on the value flag)

<applicationSettings>
    <Microsoft.MasterDataServices.Workflow.Properties.Settings>
      <setting name="ConnectionString" serializeAs="String">
        <value>Server=.;Database=MasterDataServices;Integrated Security=SSPI</value>
      </setting>
      <setting name="WorkflowTypeExtenders" serializeAs="String">
        <value>PAC=CompanyName.MasterDataWorkflow.WorkflowExtender, CompanyName.MasterDataWorkflow;OOB=Microsoft.MasterDataServices.Workflow.WorkflowTypeTest, Microsoft.MasterDataServices.Workflow, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91</value>
      </setting>
    </Microsoft.MasterDataServices.Workflow.Properties.Settings>
  </applicationSettings>
  <appSettings>

The plugin will allow you to obtain information about the calling workflow via the StartWorkflow(string workflowType, System.Xml.XmlElement dataElement) method that must be implemented as part of the interface of IWorkflowTypeExtender. You receive all the business context data via the data element parameter as an Xml snippet.

Once you have deployed this assembly and update the config files, the simplest way to debug inside Visual Studio is to go to your Project Properties, Debug Tab and Set the Startup Program to be
"C:\Program Files\Microsoft SQL Server\Master Data Services\WebApplication\bin\Microsoft.MasterDataServices.Workflow.exe".

After doing that, add a commandline parameter of "-console" which will give you a visual display of workflow plugins that have been loaded into the MDS Workflow Application Domain. It also allows you to print out to the console via Console.WriteLine() to assist with your development and debugging efforts.

Debug Setup

The MDS Workflow Console window:

As a best practice, use a PrivatePath in your Assembly Bindings in your Microsoft.MasterDataServices.Workflow.exe.config file. This will allow fusion to find your custom binaries in a subfolder rather than the binary root. Keeping all custom binaries in subfolders will help you to avoid file naming conflicts or bloating your root MDS workflow bin directory.


The simplest way to see what's going on is to just render the Xml from the workflow handler to the MDS workflow console window via an XmlTextWriter e.g.

public void StartWorkflow(string workflowType, System.Xml.XmlElement dataElement)
        {
            Console.WriteLine("workflow type: {0} ", workflowType);

            var writer = new XmlTextWriter(Console.Out);
            writer.Formatting = Formatting.Indented;
            dataElement.WriteTo(writer);

DDK

Monday 15 August 2011

Fix for Exception - "Initialization of the data source failed" in TFS 2010 Excel Reports against SSAS 2008 R2

At one of my banking clients, there was an issue with the setup of the TFS Reports in Excel. When opening the Excel reports provided with TFS, it was attempting to connect to the TFS Analysis Services Cube - and generating the following exception:

Initialization of the data source failed.

Check the database server or contact your database administrator. Make sure the external database is available, and then try the operation again. If you see this message again, create a new data source to connect to the database.




Then you get prompted for credentials, and then get a message about reinstallation of drivers.


There are a few red-herrings in the messages provided by Excel - but the underlying problem in our situation was just a permissions one.

To resolve, you just need to give the end user with the problems permissions to access the SSAS database (e.g. by adding them to the TFSDataReaders role in SSAS).  Alternatively, you can add the user as a TFS Administrator in the TFS Administration console (though this is not preferred as it is against the security principle of "least priviledge").

Till next time,
DDK