Archive for the ‘Tools’ Category
Configuring SharePoint 2010 User Profiles using AD LDS in Windows 8
Recently I published a series of three articles that provided an in-depth visual guide on how to configure SharePoint User Profiles in a Windows 8 development environment using Active Directory Lightweight Directory Services.
Part 1: Installing & Configuring AD LDS
Part 2: Configuring a web application using Forms Based Authentication and connecting it to AD LDS
Part 3: Importing user profiles from AD LDS
I hope these articles will help developers out there to get the flavor of Active Directory in their development environment without the extra luggage.
Happy SharePointing!
Configuring SharePoint 2010 User Profiles using AD LDS in Windows 8 – Part 3
In Part 2 of this series we configured a web application with FBA and connected it to AD LDS. This post will be a short one as the steps are very simple and self explanatory.
Navigate to Central Administration –> Application Management –> Manage Service Applications. Select the User Profile Service Application and click on Administrators from the ribbon. Add the sp_ups_svc account and provide it Full Control.
SharePoint provides no native method to import profiles from AD LDS. Instead, the only option out of the box is an LDIF import. Download the SharePoint AD LDS Synchronization Solution and follow the documentation. Once your profile import is complete, you will be able to see your profile from your My Profile page.
Now you can access these profile properties from your code and even InfoPath.
Happy SharePointing!
Configuring SharePoint 2010 User Profiles using AD LDS in Windows 8 – Part 2
In Part 1 of this series we looked at how to install and configure AD LDS on a Windows 8 client. In this post I will be deploying a web application in SharePoint with FBA using AD LDS as the authentication provider.
Configuring a SharePoint web application with FBA
First, we have to register the Windows account sp_ups_svc which we created in Part 1 as a managed account and we have to create a new Windows account called sp_farm and register that as well. Fire up Internet Explorer as an administrator and navigate to your Central Administrator; If you skip this step, you will find many features in the Central Administration are disabled.
Navigate to Security –> General Security –> Configure Managed Accounts and add the Windows account.
Navigate to Security –> General Security –> Configure service accounts and assign this account for the User Profile Synchronization Service.
Now create a web application with the following settings:
 |
 |
Please note that I selected sp_farm as the account for the application pool – this is very important. Once the web application has been created, create a top level site collection and assign the currently logged in Windows account as the primary site collection administrator.
Next create another site collection under this site collection using the My Sites template which we will later use to host My Sites and My Profile page.
Navigate to Application Management –> Manage Service Applications and click on your User Profile Service Application. Under My Site Settings, click on Configure Trusted Host Locations and add the new site collection we just created for My Site.
Configure AD LDS with FBA
This is the part where we tie up FBA with AD LDS. We just need to make a few modifications to the web.config files of the new web application, central administration and the Security Token Service. Make sure to make a backup before you modify them.
Web application:
<PeoplePickerWildcards>
<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="TechOneGlobalMember" value="*" />
</PeoplePickerWildcards>
<membership defaultProvider="i">
<providers>
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="TechOneGlobalMember" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="RaihanIqbal" port="50000" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="userPrincipalName" userContainer="CN=SharePoint2010,DC=TechOneGlobal,DC=local" userObjectClass="user" userFilter="(ObjectClass=user)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
<providers>
<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="TechOneGlobalRole" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="RaihanIqbal" port="50000" useSSL="false" groupContainer="CN=SharePoint2010,DC=TechOneGlobal,DC=local" groupNameAttribute="cn" groupNameAlternateSearchAttribute="cn" groupMemberAttribute="member" userNameAttribute="userPrincipalName" dnAttribute="distinguishedName" userFilter="&(objectClass=user)(objectCategory=person)" groupFilter="&(objectCategory=Group)(objectClass=group)" scope="Subtree" />
</providers>
</roleManager>
Central Administration:
<PeoplePickerWildcards>
<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="TechOneGlobalMember" value="*" />
</PeoplePickerWildcards>
<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
<providers>
<add name="TechOneGlobalRole" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="RaihanIqbal" port="50000" useSSL="false" enableSearchMethods="true" groupContainer="CN=SharePoint2010,DC=TechOneGlobal,DC=local" groupNameAttribute="cn" groupNameAlternateSearchAttribute="cn" groupMemberAttribute="member" userNameAttribute="userPrincipalName" dnAttribute="distinguishedName" scope="Subtree" userFilter="&(objectClass=user)(objectCategory=person)" groupFilter="&(objectCategory=Group)(objectClass=group)" />
</providers>
</roleManager>
<membership>
<providers>
<add name="TechOneGlobalMember" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="RaihanIqbal" port="50000" useSSL="false" enableSearchMethods="true" userDNAttribute="distinguishedName" userNameAttribute="userPrincipalName" userContainer="CN=SharePoint2010,DC=TechOneGlobal,DC=local" userObjectClass="user" userFilter="(ObjectClass=*)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
Security Token Service (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken):
<system.web>
<membership>
<providers>
<add name="TechOneGlobalMember"
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="RaihanIqbal"
port="50000"
useSSL="false"
enableSearchMethods="true"
userDNAttribute="distinguishedName"
userNameAttribute="userPrincipalName"
userContainer="CN=SharePoint2010,DC=TechOneGlobal,DC=local"
userObjectClass="user"
userFilter="(ObjectClass=*)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
<roleManager enabled="true">
<providers>
<add name="TechOneGlobalRole"
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="RaihanIqbal"
port="50000"
useSSL="false"
enableSearchMethods="true"
groupContainer="CN=SharePoint2010,DC=TechOneGlobal,DC=local"
groupNameAttribute="cn"
groupNameAlternateSearchAttribute="cn"
groupMemberAttribute="member"
userNameAttribute="userPrincipalName"
dnAttribute="distinguishedName"
userFilter="&(objectClass=user)(objectCategory=person)"
groupFilter="&(objectCategory=Group)(objectClass=group)"
scope="Subtree" />
</providers>
</roleManager>
</system.web>
We are almost there! Restart IIS using the command iisreset and navigate to the web application. You should now be able to login using Forms Authentication with the user account you created in AD LDS.
In Part 3 we will import the user profiles using the User Profile Service Application.
Configuring SharePoint 2010 User Profiles using AD LDS in Windows 8 – Part 1
If you have a SharePoint 2010 development environment setup in Windows 8 but you don’t have Active Directory you can still configure User Profiles in your SharePoint server. The process is very painstaking so get a cup of coffee, roll up your sleeves and read with full attention!
Installing and configuring AD LDS
From the Windows features list, turn on Active Directory Lightweight Directory Services.
Before we proceed with the installation, we will need to create a couple of Windows accounts as we will be needing them later. Remember to uncheck “User must change password at next logon” and check “Password never expires”.
Once the installation is done, navigate to Administrative Tools and run the setup wizard.
Click Next to begin the installation of AD LDS. We will have to create a unique instance since we do not have an instance created.
We will have to provide a unique name for the instance and this name cannot contain any spaces.
The LDAP and SSL port number must be available and not used by any other application. Take a note of these port numbers because we will need them later.
Create an application directory partition with a proper partition name and then proceed to specify the locations to store the data.
Instead of using the default Network Service account, we will use one of the user accounts that we created earlier. When you click Next, you are prompted to run the account as a service, click Yes.
If you are logged in as the administrator, you can keep the default selection as the AD LDS Administrator otherwise you will have to specify an account with administrative privileges.
The last step is to decide which LDIF files to import. For SharePoint, and for AD LDS replication, we have to import the following files:
Once the setup is complete, fire the ADSI editor using the command adsiedit.msc. In the left panel, right click on ADSI Edit and select Connect To. Provide a friendly name for the connection and under Connection Point type in the partition name which we created earlier during the installation. Under Computer type in the server name in the format Full_Computer_Name:LDS_Port. If you’re unsure about the full computer name, right click on My Computer to get it.
Click once on the connection name and then the naming container to get the following structure.
Right click on the container and create a new object of class type container with the value User.
Under the User container, we will add our SharePoint users. Right click on the User container, and create a new object of class User and enter the full name of the user. In my case its “SharePoint Test User 1”. Right click on the user and select Reset Password.
Now we need set certain properties for the user which will be later imported into SharePoint User Profile. I suggest the following properties be updated with appropriate values:
- displayName: SharePoint Test User 1
- department: Information Technology
- msDS-UserAccountDisabled: FALSE
- msDS-UserDontExpirePassword: TRUE
- msDS-UserPasswordNotRequired: FALSE
- telephoneNumber: 01710000000
- title: Software Engineer
- userPrincipalName: sp1 (Cannot contain spaces)
Similarly, you can add other users as needed. Click on the Roles container and edit the member property of the Reader role. Add the second Windows account that we created earlier here. Remember to hit Apply in the properties dialogue.
Congratulations! Your AD LDS is now ready to be used with SharePoint! In Part 2 of this series we will create a new web application and configure Forms Based Authentication and connect it to AD LDS.
Batch Update SharePoint 2010 User Logins using PowerShell
Recently I had to write a script to migrate the user logins of more than 1000 users in an organization because they had the wrong domain in their login since the organizations NetBIOS name is different from their domain name and we did not enable NetBIOS domain names on the corresponding User Profile service application. So I quickly came up with this script that iterates through the User Profile list and migrates the logins with the wrong domain to a new login with the correct domain.
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")
$contextWeb = New-Object Microsoft.SharePoint.SPSite("http://mysite");
$ServerContext = [Microsoft.Office.Server.ServerContext]::GetContext($contextWeb);
$UserProfileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServerContext);
$Profiles = $UserProfileManager.GetEnumerator();
$profile_count = 0;
foreach ($oUser in $Profiles ) {
if($oUser.item("AccountName") -like 'WRONGDOMAIN\*')
{
$oldLogin = [string]$oUser.item("AccountName");
$newLogin = $oldLogin.Replace("WRONGDOMAIN", "NEWDOMAIN");
stsadm -o migrateuser -oldlogin $oldLogin -newlogin $newLogin -ignoresidhistory;
$oldLogin + " --> " + $newLogin;
$profile_count++;
}
}
"Total Profiles Updated: " + $profile_count;
ASP.NET Web Site Administration Tool (WAT) Error
Those of us who use the ASP.NET WAT on a regular basis must have encountered this error at least once.
An error was encountered. Please return to the previous page and try again.
After some research I found out that the tool doesn’t work if you have spaces in the path of your applications directory for e.g. D:\My Stuff\Projects\Project1. I know, it’s weird!
The Solution
If you don’t want to go through the hassle of moving your project folders, worry not, NTFS Link comes to the rescue. Once you’ve downloaded and installed the tool, right click at a location of your choice and select New Junction Point.
You will then be prompted to select the target folder. In our case, this should point to D:\My Stuff\ since that is the folder that contains a space in its name.
Once the shortcut is created you can rename it to something without a space so our final path would be something like D:\ProjectsLink\Projects\Project1. The WAT tool should work now.
Visual Studio 2010 Unicode Bangla Font Support Issues
One fine day my Visual Studio 2010 couldn’t render Bangla fonts and all I saw were square boxes as you see below.
After banging my head for hours, I realized I had upgraded my Avro Keyboard after the last time I used VS2010 and during the installation I was prompted to change my default Bangla font from Vrinda to Siyam Rupali.
Little did I know that VS2010 only supports Vrinda to render Bangla in the text editor so I went ahead and changed my default font – bummer!! Luckily, I found a tool called Font Fixer which can restore your systems default Bangla font.
As you can see, my default font was set to Siyam Rupali. I clicked on Restore which then prompted me to install the Vrinda fonts manually (from my backup) and restart my computer. After booting up, I ran the tool again to confirm if the font was reset to Vrinda.
Now Bangla is being properly rendered in VS2010 and I’m one happy Bengali coder 
I’m not sure if Microsoft is aware of this issue but they need to make Visual Studio compatible with any unicode Bangla font and not just Vrinda.
HTML5 Support In Visual Studio 2010
I was trying to play around with HTML5 assuming that VS 2010 had shipped with HTML5 support but to my dismay it was not the case. Bummer! So I did a bit of homework and came up with an easy workaround. If you try googling for html5 visual studio 2010, the first link that you will see is HTML 5 Intellisense for Visual Studio 2010 and 2008. But unfortunately, the patch provided over there doesn’t seem to work. (DO I HAVE TO DO EVERYTHING!!)
So here’s how I got it to work.
- Download this archive and extract the contents to your desktop.
- Copy/Move html_5.xsd to D:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\schemas\html. The path may vary depending on where you installed VS 2010 or Visual Web Developer 2010.
- From the extracted contents, run the appropriate registry file. In my case, it was VS-2010-x64.reg
- Now fire up Visual Studio 2010 (or VWD) and navigate to Tools > Options > Text Editor HTML > Validation. On the right panel, select HTML 5 as the Target.
- Now restart VS 2010 and you should be able to code valid HTML5. Enjoy!
Discovering MSBuild – Part One
Background
This series is all about me trying to learn the dark art of MSBuild. Ever since I started developing .NET applications, I was aware of the existence of this strange tool but I could never harness its true potential. So lets begin our adventure!
Introduction
An MSBuild file typically known as an MSBuild Project File contains instructions on how to build your application step by step – neat stuff! This innovative tool from Microsoft helps you to take control over every aspect of the build process thereby helping you to automate the build and deployment process.
Overview
An MSBuild project file is basically an XML file. This XML document is defined by two XSD documents Microsoft.Build.CommonTypes.xsd and Microsoft.Buid.Core.xsd. Both these files are located in the %WINDIR%\Microsoft.NET\Framework\vXXXX\MSBuild folder. The basic structure of an MSBuild project file looks like this:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> </Project>
This structure is comprised of Properties, Items, Targets. Confused? You should be. 
Put it simply, items are the files that are going to be built and properties are the build parameters ex. Configuration or OutputPath.
Project Properties
Properties are nothing but Key-Value pairs and apparently there two different types of Properties – Static, Dynamic. What I know about static properties is that they must be contained within a PropertyGroup element which is declared directly under the project element. A project element may contain multiple PropertyGroup elements.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ApplicationName>MyDemoApp</ApplicationName>
<WhyAmICrazy>I Have No Idea</WhyAmICrazy>
</PropertyGroup>
</Project>
In the above example, ApplicationName is the key and MyDemoApp is the value(DUH!!). Can values contain spaces? I have no idea – so lets find out. Paste the above code in notepad and save it with a *.proj extension, fire up the Visual Studio Command Prompt, and execute the script.
Oppsss! Look’s like we are missing something called Targets? Not to worry, let’s dig deeper.
Tasks & Targets
Targets are the work horses of the MSBuild file so without them the file would be literally useless. Properties are utilized within these targets. A task is the smallest unit of work and a target is a sequential set of tasks. The MSBuild tool ships with a predefined set of tasks like Copy, Csc(wow haven’t used this baby in a while!), Move, Exec, etc. Tasks are invoked using parameters which are just XML attributes with values. The attributes may vary from task to task. For our example we will try out the Message task.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ApplicationName>MyDemoApp</ApplicationName>
<WhyAmICrazy>I Have No Idea</WhyAmICrazy>
</PropertyGroup>
<Target Name="HelloWorld">
<Message Text="This is my first MSBuild Application" />
</Target>
</Project>
To build this project the command should be of the format
msbuild FILE_NAME /t:TARGET_NAME
For our example the command would look like
msbuild Sample1.proj /t:HelloWorld
You will see that the build succeeds without any errors! We may have won the battle but not the war
A more complicated example for you adrenaline junkies out there:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ApplicationName>MyDemoApp</ApplicationName>
<WhyAmICrazy>I Have No Idea</WhyAmICrazy>
</PropertyGroup>
<Target Name="HelloWorld">
<Message Text="This is my first MSBuild Application and $(WhyAmICrazy) why I love .NET" />
</Target>
</Project>
Until the next episode..
Using MsSqlSpatial with Google Maps
One of the many .NET open-source projects that don’t get the attention they deserve is MsSqlSpatial. This project provides spatial extensions to SQL Server 2005 – meaning you can perform various spatial calculations right in your T-SQL queries! Cool eh? But, this project lacks documentation which is a problem for us developers. I’m sure they are working their ass off to make one but in the mean time we have to play around with the code to understand its inner workings.
Since Google Maps is very popular among developers, and my personal favorite, I thought why not give out some tips.
Spatial Reference Identifiers (SRIDs)
Most of their functions, require this as a parameter. If your GIS application uses Google Maps then you should use 4326.
Code Examples
Convert a Point on the map from a Well-Known-Text(WKT) format to a Well-Known-Binary Format:
SELECT ST.PointFromText('POINT(-87.6673250 41.9489650)', 4326)
The Point should be of the format POINT( longitude latitude ).
Polygon to text:
SELECT [Bloggernate].[ST].[PolygonFromText] ( 'POLYGON((-87.71956443786621 41.96727630029047,
-87.64369010925293 41.96765920367816,
-87.6309871673584 41.920672548686824,
-87.72522926330566 41.91939525416699,
-87.71956443786621 41.96727630029047))'
,4326)
The polygon must be a closed one otherwise you’ll receive an exception.
Check if a polygon contains a specified point:
SELECT [ST].[Contains] (YOUR_WKB_POLYGON, YOUR_WKB_POINT)
I hope this provides a good starting point for those daring to step into the unknown
Happy Programming!