Thursday, March 28, 2013

Enabling SharePoint Document Management in Microsoft Dynamics CRM 2011

If you want to enable SharePoint Document Management integration with Microsoft Dynamics CRM 2011, you will need to have SharePoint 2010 (or SharePoint 2013) already set up and installed.

In your SharePoint environment, it is recommended that you first install the Dynamics CRM List Component to your SharePoint Web Application/SharePoint Site Collection.

You can download the CRM List Component from here:

The instructions for installing the CRM List Component are included with the download page, but here are a few screenshots on how to accomplish it:

  1. Go into Site Actions-->Site Settings
  2. Beneath the Galleries heading, click on Solutions
  3. Upload and Activate the Solution

If you are unable to Activate the Solution in the Solutions Gallery, 

  1. Log into Central Administration and go into Application Management
  2. Beneath Service Applications, click on Manage services on server
  3. Make sure that the "Microsoft SharePoint Foundation Sandboxed Code Service" service has been started

In order to configure Dynamics CRM 2011 for SharePoint Document Management, you can do the following:

  1. Click on Settings
  2. Click on Document Management
  3. Click on the Document Management Settings icon
  4. Go through the Wizard to configure the SharePoint site along with its corresponding entities in CRM.

Now, when you navigate back to Dynamics CRM and open a CRM record, you should be able to view the CRM List Component view when you click on Document Management:

Wednesday, March 27, 2013

SharePoint Custom Claims Provider on CodePlex

If you have a basic requirement to implement a Custom Claims Provider in your SharePoint 2010 or SharePoint 2013 environment to integrate with either your Active Directory or LDAP repository, you no longer have to write a Custom Claims Provider from scratch!

CodePlex now has a project for a Custom Claims Provider that is packaged as a SharePoint Farm Solution that can be readily deployed to either your SharePoint 2010 or SharePoint 2013 Farms:

SharePoint 2010 Custom Claims Provider

SharePoint 2013 Custom Claims Provider

Monday, March 25, 2013

Visual Studio Toolbar differences between Visual Studio 2010 and 2012

If you are switching from Visual Studio 2010 over to Visual Studio 2012, most of the main toolbar menu headers should be the same.

However, the ONE major difference between the 2 IDEs is the switch from the Data menu item to the SQL menu item.

In the case of Visual Studio 2012, while the SQL menu item replaces some of the functionality for Schema and Data Comparisons, as well as the Transact SQL Editor, it does not completely replace the Data menu item.

In the case of the Data menu item, you also have 2 menu items for "Show Data Sources" and "Add New Data Source".  

While neither of these menu items seem to exist in Visual Studio 2012, you can perform these same operations in the Data Sources pane which is usually hidden along with the Toolbox.

Wednesday, March 20, 2013

Classic Shell vs. ViStart

If you have examined available FREE Start Menu alternatives for Windows 8, you may have come across 2 particular alternatives called Classic Shell ( and another alternative called ViStart (

I compared the 2 of these products and came up with the following differences:

  1. ViStart does not allow spanning the Start menu across multiple monitors
  2. ViStart has an extended load time and is filled with adware during the installation
  3. ViStart does not have an option to launch Windows Explorer by right clicking on the Start Menu icon
  4. ViStart does not provide additional Start menu options such as Printers or Network Connections
  5. ViStart does not have the extensive set of right-click menu options as presented in Classic Shell
  6. ViStart has poor searching functionality and cannot find items such as "inetmgr"
  7. ViStart does not have the ability to install the Start menu for "All Users" of the system while Classic Shell does have such functionality.
  8. ViStart does not uninstall "cleanly".  It leaves traces of "Start" as a text menu item with no associated Start menu orb.
  9. ViStart displays with a "shadow background" on Windows Server 2012 rather than integrating seamlessly into the Windows Server 2012 Taskbar.
  10. ViStart has special "Metro" Start menu items for "Show Metro" and "Show Metro Apps"
  11. ViStart provides additional skin options other than the standard look and feel associated with past versions of Windows ranging from Windows XP, Windows Vista and Windows 7.
  12. Both ViStart and Classic Shell provide an option to skip the Metro User Interface and go directly to the Desktop.
  13. Classic Shell uses a "Shell" icon instead of the traditional Windows 7 Start menu icon
  14. Classic Shell groups the Programs and Apps separately into a Windows XP style set of program groups vs. ViStart which offers the full "traditional" Windows 7 Start Menu interface

Classic Shell

ViStart on Windows 8

ViStart on Windows Server 2012

ViStart Uninstallation "Start" menu

Overall, Classic Shell is the clear winner in terms of features and functionality that mimic the original Windows 7 Start menu!!

Creating a custom ASP.NET or WCF Web Service for SharePoint 2010

If you are looking at writing and deploying a custom ASP.NET or WCF Web Service for SharePoint 2010, you can follow the MSDN walkthroughs to accomplish this.  Though the articles refer specifically to SharePoint Foundation, you can also apply these same practices while deploying your web services to SharePoint Server.

NOTE: You should also make sure that your services are created and deployed on the .NET 3.5 platform, otherwise you will receive a PlatformNotSupportedException when attempting to execute your code.

Walkthrough: Creating a Custom ASP.NET Web Service

Walkthrough: Creating and Implementing a Custom WCF Service in SharePoint Foundation

Monday, March 18, 2013

Where can I find the WCF Tools such as WCFTestClient.exe?

If you are looking for WCF Tools to test out your WCF Service, locating all of the various tools can be a little bit confusing since they are found in different locations.

For example, if you are looking for WcfTestClient.exe, this can be found at C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE (for Visual Studio 2012).

However, if you are looking for some other debugging tools for WCF Services, they can instead be found in the Windows SDK directory here:  C:\Program Files (x86)\Microsoft SDKs\Windows\v.8.0A\bin\NETFX 4.0 Tools (for Visual Studio 2012).

Some of the tools that can be found in the Windows SDK directory include the following:

  1. SvcConfigEditor.exe
  2. SvcTraceViewer.exe
  3. SvcUtil.exe

Tuesday, March 12, 2013

Little Known PowerShell Tips & Tricks

  1. PowerShell script blocks can contain a begin, process and end script block as described here: or here:
  2. In order to access Microsoft.NET Static methods, you can use the double colon notation in front of the respective Microsoft.NET Class such as described here:
  3. You can embed C# class within PowerShell scripts as described here:
  4. You can even assign script blocks to variables as described here:
  5. You can write out long strings using Here-Strings as described here: and here:
  6. You can send output to the console as well as a variable as described here:
  7. You can get a listing of PowerShell command aliases as described here:
  8. You can define parameters explicitly (instead of using $args variable) as described here:
  9. You can validate your script parameters as described here:
  10. You can use Invoke-Expression or Invoke-Command to command presented as strings as described here:
  11. You can test out your commands before actually executing them by using the -whatif parameter as described here:  You can also easily add -whatif support to your own PowerShell functions as outlined here:
  12. To work with Key/Value Pair Collections in PowerShell, you can use Hash Tables:

Friday, March 8, 2013

Removing Roles and Features in Windows Server 2012

Unlike in previous versions of the Server OS, in Windows Server 2012, you do not simply re-run the Roles and Feature Wizard to uncheck the Roles and Features that have already been installed (though the process is only slightly different).

Instead, you must go into the Dashboard for the Local Server and navigate to the Roles and Features section to remove individual roles and features.  You can select an individual role or feature for removal and then right click on the selected Role or Feature to remove it.  After selecting this menu option, this will once again open the Remove Roles and Features Wizard whereby you can unhceck the roles and features you wish to specifically remove.

Thursday, March 7, 2013

Testing an ADFS Installation without SharePoint

If you are planning a deployment of SharePoint with Claims-based authentication using ADFS (Active Directory Federation Services), chances are you will want to set up ADFS on a separate server and verify that it is working properly before you configure it to work with SharePoint.

Normally, you would have to set up a test application such as an ASP.NET Web Application using the Windows Identity Foundation SDK to verify the functionality and integration of ADFS.

Fortunately, there is a little known feature in ADFS once it is installed which allows you to test an installation of ADFS without an application!

This feature is in the form of a page called IdpInitiatedSignOn.aspx which is located in the root of the /adfs/ls directory.  Therefore, it can be found at a Url similar to the following https://<adfs fqdn>/adfs/ls/IdpInitiatedSignOn.aspx

You can find this page by browsing the Content View in IIS to locate the name of the page:

If you want to simplify your life further, you can turn on FormsSignIn and make it the default authentication type in the web.config file (located beneath C:\inetpub\adfs\ls).  By default, the FormsSignIn.aspx element is not the first element in the web.config file.  You can simply cut and paste it as the first line below localAuthenticationTypes as shown in the screenshot below:

Once you have everything configured, you should be able to log into the IdpInitiatedSignOn.aspx page and see a page similar to the following:

If you are able to successfully log into your ADFS instance using your Windows Active Directory credentials, you have correctly setup and configured your ADFS installation and can proceed with integrating ADFS with SharePoint as a Trusted Identity Provider!


Internet Explorer 10 now available for Windows 7!!

If you have been waiting for Internet Explorer for Windows 7 to be released, the wait is finally over!!

You can download Internet Explorer 10 from here:

If you are looking for the offline or standalone installations of Internet Explorer 10, you can find them here:

Wednesday, March 6, 2013

Enabling RadControls in the Sitefinity Toolbox

If you wish to use the RadControls in your Sitefinity Content Pages, you will notice that, by default, the RadControls are not available as widgets to be added to your Sitefinity Content Pages even though Sitefinity ships with the Telerik RadControls (by way of the Telerik.Web.UI DLL/Assembly).

Fortunately, you can enable the RadControls by going into the Toolbox and enabling them so that they display amongst your available widgets:

  1. From the Administration menu, select Settings
  2. Click on Advanced
  3. Expand the Toolboxes node to view the following:  Toolboxes-->Toolboxes-->PageControls-->Sections-->RadControls
  4. Click on the RadControls menu item
  5. Select the Enabled check box to enable the RadControls widgets
  6. You should now be able to add RadControls to you Sitefinity Content Pages!

Tuesday, March 5, 2013

Changing the Color Scheme in Visual Studio 2012

If, like me, you do not like the color themes that ship out-of-the-box with Visual Studio 2012, fortunately, Microsoft has recently released a Visual Studio 2012 Color Theme Editor!!

You can read more about the Visual Studio 2012 Color Theme Editor as well as download it from here:

Friday, March 1, 2013

Intellisense for SharePoint Libraries in PowerShell using PowerGUI and PowerSE

If, like me, you have become addicted to Intellisense and autocompletion from years of Visual Studio, you will be quite a bit disconcerted when you begin working with PowerShell (at least v. 2.0) even in IDEs such as PowerGUI ( and PowerSE (

Unlike, Visual Studio which creates the Intellisense and autocompletion of the libraries at design time, most of the Intellisense in PowerShell is actually generated after some code has been executed.  Therefore, while you are simply typing and referencing libraries you will not have that wonderful autocompletion and dynamic help for object members like you have in Visual Studio.

Even worse, when you are referencing these libraries, due to the implicit typing of PowerShell, you will not be able to figure out the output of methods and properties when referencing libraries such as SharePoint within PowerShell.  This makes it particularly difficult to look up the appropriate reference APIs in the MSDN documentation or determine what is not working correctly when something breaks or throws an exception.

Unfortunately, while you cannot overcome ALL of the limitations of using PowerShell, you can certainly overcome some of the Intellisense problems (even if only partially).

So how do you do that?  By using the capabilities of Executing a Selection of code in PowerShell to load up the appropriate library and object references to display Intellisense in either PowerGUI or PowerSE.

In the above screenshot, I highlight a selection of PowerShell code and selected "Execute Selection" in PowerSE.  In this manner, I can get PowerSE (or PowerGUI depending on your preferred PowerShell editor of choice) to display the Intellisense for any subsequent SharePoint libraries that I need to use.

So while doing this for every few segments of code that you want to use is INCREDIBLY annoying, at least it is better than nothing and offers you some additional error checking while you are typing and referencing various SharePoint libraries as well as provides the added convenience of being able to leverage PowerShell scripts for executing various tasks in SharePoint without having to compile and deploy .NET assemblies to accomplish those same tasks.

NOTE: It is best to execute selections of code after every few lines that you type so that variables and their respective values remain in memory throughout the composition of your script.  Otherwise, you will have to create local variables and assign them values if the referenced variables have not already been loaded into PowerShell memory.  If the variables do not exist for a particular segment of PowerShell code, you will get an error/exception message just as you would with .NET (since PowerShell is based on .NET, this makes logical sense)