ReBlog: Things that Should be Easy: Presence Awareness in WSS V2 and WSS V3

Things that Should be Easy: Presence Awareness in WSS V2 and WSS V3

I found this post today when working out some issues I seem to be having on my machine while looking at the presence of users. There's some good stuff in here. When I get the issues worked out, I will detail my findings as a follow up.

A simple method for finding Active Directory user information using C# with LDAP

I spent hours trying to find a simple way to get user data our of AD from an LDAP query. Turns out you don't need to do a lot of crazy stuff, and looking at my code when I was done, it turned out to be a lot easier than it seemed when I started out.

The only thing I need to pass in to my function was the name of the property (see the list here), and the username. In my case it was coming from some other logic I had to write to get the users of a group that was a member of a SharePoint site.

Also the ldapPath I pass in to the DirectorySearcher constructor was simply "LDAP://mydomain.com"

This returns the value of the property of the user that you specify as a string. Example:

getValidADProps("mail", "Ima User") will return the AD email address for Ima User.

In the function, I used a try/catch in the instance that the property you are trying to find isn't there, you will get a index out of range error.

I will say that this is not the more lightweight method, according to my findings. For a more specific return set from the searcher you may want to look into the PropertiesToLoad Property of the class.

public string getValidADProps(string _prop, string _username)

{

DirectorySearcher ds = new DirectorySearcher(ldapPath);

ds.SearchScope = SearchScope.Subtree;

ds.Filter = "samaccountname=" + _username;

SearchResult sr = ds.FindOne();

try

{

if (!string.IsNullOrEmpty(sr.Properties[_prop][0].ToString()))

{

return sr.Properties[_prop][0].ToString();

}

}

catch (Exception)

{

return string.Empty;

}

return string.Empty;

}

 
 

HTH,

Eric

A cool way to use Properties in a SharePoint Web Part

Properties are nothing new in OOP, but something that I stumbled upon not too long ago was a cool thing that you could do with properties. My work was SharePoint web part related, but I imagine that it would work with any customized object that can be called in your page.

I needed a way to reuse a webpart that was accessing a single User Profile field so that I could display any field I wished, as many as I wanted just by simply dropping a new custom web part on my page in SPD and simply adding a name/value pair to the HTML.

The idea here is to build your web part with a property:

public string CustomProperty
{
  get { return _CustomProperty; }
  set { _CustomProperty= value; }
}

Nothing crazy here but later in the code we check the CustomProperty property for a value and if it's valid, we go and grab the field from the User Profile database and then display it in the web part:

<WpNs0:ProfilePropertyPart runat="server" CustomProperty="FirstName" .../>

So the trick to making this work is to make sure you use the correct nomenclature for the value you pass into the CustomProperty property.

The value you need is found on View Profile page (found here - Central Admin/Shared Services/User Profiles and Properties/View Profile Properties).

Find the field in the "Property Name" column, click it and chose "Edit" and in the Property Settings block, you should see a "Name" field and a "Display Name" field. You want to use the "NAME" field. SharePoint uses this as it's logical name and it is the value you need to pass into the CustomProperty property of the web part declaration!

In this case with the "First Name" field, the SharePoint logical field is actually "FieldName" with no spaces. Some fields use the same value for 'Name' and 'Display Name', others are close like the 'First Name' but slightly different. and others still can have prefixes that don't make sense, ie. if you create a custom field, the value that SharePoint gave me for the 'Name' of the field was "SPS-Skills", which is what I passed in to the CutsomProperty property.

Of course you'll need admin rights on the server to get to that page.

I will go more into accessing values from the User Profile database in a future posting, but I thought this was a really cool thing you could do for an easy way to customize a web part so that you could reuse it and get different output simply by changing the value of a property in your html in designer.

Get users of AD group for use in SharePoint webpart.

Welcome to my first technical posting.

My task here was simple, create a web part that displays the users of an Active Directory OU (Organizational Unit or group basically) which will have been added to a SharePoint site. This is our model internally going forward on how we are managing access to sites within our farm, so basically every site will only have one member... an AD group. This way we can manage (or let someone else manage) access through AD.

I won't get into how to create a web part in this post (you can start here if you like), but more of the guts of what I used to get what I needed out of .NET in a web part. This is really basic to the rendered output is nothing fancy.

Basically I got the site's userlist from the site context, iterated the user list, checked to see if the user was a group, if so, called code to give me the AD users of that group and output the user list.
First add a reference to:
System.DirectoryServices.AccountManagement;

Here's the code:
First: this code was inside the
protected override void CreateChildControls() function.

string currentUrl = System.Web.HttpContext.Current.Request.Url.ToString();
SPSecurity.RunWithElevatedPrivileges(
delegate()
{
using (SPSite site = new SPSite(currentUrl))
{
SPWeb web = site.OpenWeb();
SPGroupCollection grps = web.Groups;
foreach (SPGroup group in grps)
{
if (group.Name == web.AssociatedMemberGroup.ToString()) //This gets the users/group from the current site
{
Controls.Add(new LiteralControl("" + group.Name + "
"));
foreach (SPUser user in group.Users)
{
if (user.IsDomainGroup)
{
string groupName = user.Name.Remove(0,5);
using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, domainName))
{
if (ctx != null)
{
GroupPrincipal gp = GroupPrincipal.FindByIdentity(ctx, IdentityType.Name, groupName);
if (gp != null)
{
foreach (Principal p in gp.GetMembers(true))
{
Controls.Add(new LiteralControl(p.Name + "
")); ....(bracketd removed for brevity)

Sorry for the lame code spit out, I'm still new to blogspot.
One thing I wanted to point out here was:

string groupName = user.Name.Remove(0,5); You can manipulate the string however you like (Substring etc.) but what took me a while to figure out was that GroupPrincipal.FindByIdentity expects the group name without the domain\ prefix, so in my case my domain name is only four letters and a '\'. This took me way too long to figure out, and no offence to M$, but sometimes the documentation just doesn't specify that in easy to understand terms.

Also, here's a link to Brad Rutkowski's blog where I found the base code for getting members out of a group.

Hope this helps someone out there.

-Eric

Allow myself to introduce... myself.

Blogspot, here we go!

Okay, so I have a MySpace page, facebook, friendster, twitter, Tumblr, and now a blogspot account. The reason for this new blog for me is that I never really had a place to put things about what I learn in my career anywhere. All that other stuff is fun and cool for keeping in the loop about all things viral and fun, but none of them are really places that I could put anything of substance.

My goal for this blog is to mainly put things up here that I learn about my chosen profession of web development. I have been a professional developer for about 4 years now, so not too awful long considering I graduate 4 years ago fresh into the industry. I know some things, and not a lot about a lot more, but hopefully, I can help someone following in my footsteps find the answers, in layman's terms to some difficult, and maybe not so difficult programming and web development issues, most of which going forward will probably be about programming web parts in Share Point 2007 and the upcoming (very soon) 2010. Most of my posts may seem very rudimentary to seasoned .NET professionals, but I surmise that no one person can know everything there is to know (well, except maybe for Scott Guthrie) and we all have to start somewhere.

Sit back and enjoy. I hope to post lots, but we'll see how that goes as time permits. I already have one post I want to share but I had to get this one out of the way.

Thank you,
Eric