Daniel A. Galant

Leveraging Themable CSS

Daniel Galant — Thu, 03 Mar 2011 19:57:45 GMT

There have been many changes and improvements with the release of SharePoint Server 2010 and how it implements a number of features and services. One of those features is the manner in which Themes are created, applied and customized in your SharePoint deployment. While playing with the new theming engine, I came across a number of articles and posts dealing with how to create themes using Office applications, such as PowerPoint and Word. However, there were not many that dealt with the customization of your CSS through the use of the new Theme Comments that SharePoint will leverage in order to apply your theme scheme to your customized Cascading Style Sheets (CSS).

This article deals with that very topic as I’ll endeavor to guide you through how to create and apply theme comments to your custom CSS so you can indeed leverage Themes in SharePoint 2010. To start off, let’s simply take a look at attaching some custom CSS to a Master Page in order to apply our own styles to the SharePoint site.

While there are several methods for attaching a custom style sheet to your Master Page, best practice dictates using the <SharePoint:CssRegistration> link in the <Head> of your Master Page. With SharePoint 2010 now supporting the After property, you can ensure that your custom CSS is applied after SharePoint’s core styles.

Now we’ll also add a custom header image to the page so that we’ll be able to leverage the RecolorImage token as well later in the article.

Let’s take a look at the CSS itself.

Notice the body #s4-ribbonrow setting the background-color as well as the TopHeader class pointing to our custom image. There are no theme comments added to the CSS yet, so the ribbon row color won’t be affected when you apply a theme to this site and no changes will be made to the header. Setting the new master page as our default master for the site will now render the site as in the image below.

If you then apply a theme to the site what happens? Let’s use the Vantage theme and see what the effect is.

Notice the changes to the TopLink, QuickLaunch and settings page, but the ribbon row and custom header remained the same. In order for these elements to also be affected by applying a theme, you must add the appropriate theme comments to your custom CSS.

In order to leverage theme comments when they are added to your custom CSS, you must first be sure to place your CSS files into the proper location within your site so that SharePoint will actually read them and apply the settings to your pages. For theme comments to be read by SharePoint when you apply a theme, you need to place your custom CSS files in a folder called Themable that you create in the Style Library of your site. This folder does not exist out of the box, nor will it be created magically for you when using custom CSS and theming.

The Style Library before:

The Style Library after creating the Themable folder:

Once you have created the Themable folder, import your custom CSS files into this location and be sure that your registration links are pointing to these files and not somewhere else in your site. Now to make your styles leverage themes when applied, you need to add the theme comments to your CSS.

There are three different tokens that can be leveraged by your CSS, ReplaceFont, ReplaceColor and RecolorImage. I’m not going to go into depth on the effects or properties of these elements here but ReplaceFont will let you change certain font elements to use one of the two available theme fonts, ReplaceColor allows you to substitute any of the 12 theme colors into your styles and RecolorImage will allow you to use any of the 12 theme colors in your images. We’ll see more on this later.

Right now we are going to add a comment so that the ribbon row will be effected when you apply a theme to the site. Since we are trying to leverage the theme’s colors to apply to the ribbon row, we’ll use the ReplaceColor token. The syntax for the comment is as follows:

/* [ReplaceColor(themeColor:”color”, property:”value”)] */

In the above comment, color represents one of the 12 theme color choices that you want to use to replace the color property of your style such as Dark1 or Accent5. For property you can use either themeShade or themeTint to darken or lighten (respectively) your color choice with a value between 0.0 and 1.0. Be aware that if you are not going to use the property:”value” option, do not include the comma in your comment. Doing so will cause SharePoint to skip your comment and you’ll be trying to figure out why your choices are not being applied.

The image below shows the theme comment added to the custom CSS file.

This line simply tells SharePoint to replace the background-color #abc830 with the themes Dark2 color. You’ll now save your modified CSS and try applying a theme. Once again I used the Vantage theme. The image below shows you the 12 colors defined by this theme.

The result of applying this theme at this time is the following.

Alright. So what happened to the ribbon row and the custom header we applied? Here you see the first of several issues you can run into when trying to use theme comments with your custom CSS. The site that I am working with in this example happens to be a publishing site and so the Style Library is under content approval. This means that any changes made to its files need to be published as a major version and approved before they can be properly used. Now while SharePoint seems to read and apply changes made to the CSS styles without having to go through all this, it does not process your theme comments until you have an approved major version of the file. As a matter of fact, as can be seen here, it seems to completely disregard the style altogether.

After publishing the file as a major version and approving it let’s apply the theme again. Theme comments are only processed at the time the theme is actually applied to the site. Therefore, any time you make a change to your file you will need to re-apply your theme to see the effect.

Here you can see that the ribbon row has now picked up the Dark 2 color of your theme, but the header is still the original green color. To change this you need to use the RecolorImage token in the header’s style declaration. The syntax for the RecolorImage token is as follows:

/* [RecolorImage(themeColor:”color”, method:”value”)] */

Once again color is the theme color you want to use with your image. Value can have one of three values, Tinting, Blending, or Filing. Tinting uses your theme color for the image colors, Blending mixes your theme color with the original color of the image and Filing completely fills the image shape with your selected color. In the image below you’ll note that I am going to recolor the image using the Accent 2 color and tint the image.

Again you need to publish and approve the CSS file after making the change and then reapply the Vantage theme. The result is as follows:

If you choose to use the Blending option it would look like this:

One point I would like to make here, in my experience the value is case sensitive, Blending will work but blending will not.

So you can see that you have several options when it comes to themes and your custom CSS. Take some time and play around with the choices provided by using theme comments and see what effects you can come up with for your sites.

I hope this article helps you avoid some of the issues I ran into and gets you smoothly on the theme scheme highway. Till next time….

SharePoint Architecture–A view from space

Daniel Galant — Fri, 18 Feb 2011 23:07:06 GMT

There is no denying that SharePoint is finding its way into more and more organizations and people from all aspects of a company find themselves interacting with, working on and designing for the corporate SharePoint deployment. Often they find themselves dealing with terms such as Farm, Web Application, Site Collection and other SharePoint terms that, for them, hold various other meanings and connotations. Today I thought I would share with you an analogy I’ve been using for sometime now whenever I need to describe the SharePoint architecture. Whether you’re a techie, the marketing guy or even a CEO, relax and come along for the ride.

Imagine, if you will, that you are a space explorer who has been tasked with finding and colonizing a new world to help support and bring new life to your dying home planet and its population. You have been traveling through the cosmos and have at last located a planet you feel will do very nicely for your purposes. You land your craft and establish your base of operations from where you will begin the task of colonizing this new world. As you are the first person to set foot on this new world you get to name it and call it SharePoint. You have now claimed your planet, your Farm, for your home world's population to use and have your base of operations established, Central Administration, from where you can control the colonizing effort. Now the task of terra-forming must begin as you need to prepare the world to welcome it’s new inhabitants.

The first thing you need to do on this new world is create the continents upon which you can build the structure of this new world. How many continents you need is up to you and the requirements set forth by the home worlds governing rulers. Each continent will provide you with a land mass that you can then carve up into manageable units. These continents server as the web applications of your SharePoint farm and provide you with the address space, or URL, that your population will use to find their new homes.

Once you have the continents prepared you can now divide them up into individual countries that will actually govern and rule the people of your planet SharePoint. Each country is a sovereign state and will be responsible for the safety and security of its people. Countries do not share resources with other countries as resources are vital to the health and welfare of the people of that country. Furthermore, in its initial state, each country maintains a closed border policy. This means that citizens of one country cannot travel to or visit any other country. Now it is possible for one country to decide to open its borders and grant entry to the people of another country, but that is strictly up to each country on a case by case basis. These countries are the Site Collections in your SharePoint deployment

Countries can be large, small; they can be a single kingdom or they can be further divided into additional political entities such as states or provinces. Each state can have its own set of rules and security, but it still must conform to certain rules put forth by the countries governing rulers. Much like the United States is made up of 50 states, each state with its own rules and policies, each state must still abide by certain federal laws and regulations. Unlike countries, however, there is free trade between the states or provinces of a given country and the citizens of that country are free to travel from state to state. Now while it is possible for a state to enforce its own security and close its borders to some of the population, this can hinder the functioning of the country, as a whole, and interfere with the general feeling of co-operation that you are trying to foster on your new world. The states or provinces are the Sites in our SharePoint deployment.

Your states can be further divided into counties and cities as you see fit or the need drives your colonization effort. At any level though you will have offices and services that are used by your people to do their work or store their belongings. These are the lists and libraries that will populate your sites and subsites throughout your Site Collections within the Web Applications that are all part of your new SharePoint Farm.

So what have we got here? You find a planet, your farm. You establish a base of operations, Central Administration. You create continents, Web Applications. On the continents you establish countries, Site Collections. You can divide the countries into states or provinces, Sites or Subsites. These can be further sub-divided as needed. You create offices, schools, stores, etc., lists and libraries. Bingo, SharePoint.

If someone comes along who doesn’t like how you have setup your world or the rules you have established, well, they can go find another planet and start their own SharePoint farm. After all, it’s your world.

SSWUG Virtual SharePoint Conference

Daniel Galant — Wed, 31 Mar 2010 10:21:00 GMT

The folks over at SSWUG.org will be hosting another of their virtual conferences this April 7-9. If you have never thought of attending a conference held over the Internet, give this a look. The people behind the SSWUG VPCs do a wonderful job and you might just pick up some really good information as well.

To register just go to SSWUG Spring 2010 VPC and be sure to use the VIP code DGalantSPVC10 to save $30 off the cost. I'll be giving four different sessions thia time around, two on SharePoint 2007 and two on SharePoint Designer 2010. Check out their site for a full listing of the sessions and speakers.

Hope to see some of you there.

SharePoint Designer 2010 – I know, it’s Beta

Daniel Galant — Fri, 04 Dec 2009 15:38:27 GMT

So, like many other folks out there I’ve been playing with the new SharePoint Designer 2010 public beta, and also like many of you, I’ve been liking a lot of what I’m seeing. Still, I keep running across issues that I really hope get fixed before the release. This one has been plaguing the product since the early betas and I really hope it gets addressed before final release. As of now, SharePoint Designer cannot connect to a SharePoint site if you have any additional host headers attached to the site. For many organizations I would say this is a big limitation. As an example, say you have created your portal application at the following address, portal.acmeman.net. Now, for the sake of your internal users you decide to add the header of simply portal, so that your users don’t have to enter the entire FQDN when accessing the site. Your IIS would look something like this,

Unfortunately, now when you try and open the site from Designer you’ll get the following error,

Clicking OK will then present you with this,

The fix is to simply remove the offending additional header and the site will once again become accessible. Again, I will point out that this is still a Beta product and I have every confidence that Microsoft will have this working by release. None the less, I wanted to put this out there and raise some awareness of the issue amongst the Designer community.

New Workflow Functions with SharePoint Designer 2010

Daniel Galant — Tue, 20 Oct 2009 01:02:00 GMT

Now that the SharePoint Conference is under way, we can start talking about all of the cool things you will be able to do with the new version of SharePoint and its related products once it hits the streets sometime next year. First of all, let me start by saying that Steve Ballmer announced during the keynote this morning that the public beta for SharePoint 2010 will begin sometime in November. So keep your eyes and ears open for when you will be able to start downloading the bits and start your own explorations. For now, I’ll just tell you about some of the things that are coming our way to make working with and designing on SharePoint a bit more fun and cool. As with the current version, SharePoint Designer will still be a free product in its 2010 form. However, you will not be able to use it to customize your SharePoint 2007 farms, as it will only work with SharePoint 2010. So if you are going to be supporting both environments, you will need to use both tools. Don’t be discouraged, there are good reasons for this. In my upcoming posts I’m planning on discussing several of the key features and enhancements that are being made within SharePoint Designer 2010, such as a new interface, new security options, new management tools, new integration options and yes… new workflow features. In this post I’d like to focus on some of the enhancements that are being made to the workflow design options when using SharePoint Designer 2010.

You know how with Designer 2007, we can only create a workflow that is attached to a single list or library? Gone. You know how we have to get out Visio, or perhaps some other design tool, and draw out the logic flow of the workflow process (or at least you SHOULD be drawing out the logic flow of your workflow process), and then have that diagram close at hand as you start working your way through the Designer Workflow Wizard to create the actual workflow? Wouldn’t it be really cool if you could take that Visio drawing that you spent all that time creating and use it as a template for the workflow directly? Guess what. Would it be neat if you could create a workflow once, and then reuse that workflow again on another list? You got it. All these things, and more, are now possible with Designer 2010. When you create a new workflow using Designer you actually have three different types of workflows you can create. First, you still have the option to create a workflow that is specific to a list or library. Second, you can now create a Site workflow that is usable anywhere within the Site you are attaching it to. Third, we have the Reusable workflow that can be attached directly to a content type, or can be used by all content types. How cool is that?

It gets better. As I mentioned, there is now also integration between Visio 2010 and Designer 2010 such that you can map out your workflow logic in Visio using the new SharePoint Workflow Template, then export that design to a file and import that into SharePoint Designer where you complete the specific configuration options for the conditions and actions. I’ll be showing you how this is done in an upcoming post so be sure to check back here to see just how this is done. But that’s not all. You can also export a workflow you have created in Designer and import that into Visio and render it out as a diagram, modify the diagram, re-export/import and continue working with it. All this makes for a much more robust workflow design solution, and all still without having to write code.

Hey, have you ever wanted to modify those out-of-the-box workflows that Microsoft gave us? You can now. And yes, these can also be exported and diagramed out in Visio, just like your from scratch custom workflows. There are a number of new conditions and actions that are now included, out-of-the box, as well. Conditions such as, check list item permission or person is a valid SharePoint user. Some of the new actions include items such as lookup manager of a user, assign item for approval, replace list item permissions, or delete previous versions. You can also create an impersonation step, whereby that specific step of the workflow runs under the authority of the user that last edited the workflow itself, and not as the user who actually started the workflow on the item in the list. When you create a reusable workflow, you can specify new columns that the workflow will create in the list that it is is attached to using the Association Columns feature of the workflow creator. This allows you to have columns that are referenced within the workflow and be assured they will be included in the list where the workflow is being used.

We also still have the features that are near and dear to us, serial and parallel processing of actions, if/else branching, multi-step workflow design as well as task forms and initiation parameters. Although the Workflow Design wizard as you know it in Designer 2007 is gone, the addition of the Office Ribbon in Designer 2010 still gives us the control and context awareness for creating workflows and actually integrates more smoothly into the Designer work surface.

It seems that Microsoft did indeed listen to a number of the pain points we griped about with the current version and is making great strides to ease those pains in the new release. I, for one, am very excited about the improvements that are coming with the new version of SharePoint.

SharePoint User Permissions - Who's responsible?

Daniel Galant — Thu, 18 Jun 2009 22:24:00 GMT

A question that often comes up when dealing with a new SharePoint deployment is, “Who should control the assignment of user permissions to a SharePoint site?” Many times the instinctive response to this question is, the Network Administrator's, of course. As standard as this might seem in most organizations, when it comes to SharePoint this is actually not the avenue that we want to take. SharePoint is, by its very nature, a User based product, and as such should be under the control of the users who must use and maintain the data within.

The SharePoint boundary for permission inheritance really begins with the Site Collection. Each Site Collection maintains its own list of roles and users assigned to those roles as well as the level of access each role has within that Site Collection. Inside of the collection this inheritance can be broken at any level, sub-site, list, library or even item. While this is not really a best practice, due to the limitations within SharePoint for managing permissions, it is often a necessity to control who has access to specific information within the collection. The issue is that SharePoint itself has no mechanism for reporting what permissions a user or group has within its boundaries. While you could check each site, list or item to see what permissions someone has to that item, you can't see the permissions that are assigned someone throughout the Site or Collection. Also, SharePoint has no means of copying one users permissions to another should you need to do this. There are 3rd party solutions that can assist you in handling some of these limitations however, such as DeliverPoint from Barracuda Tools or Quests Administration Tools for SharePoint.

What this means is that a role must be created for each level of access that a different set of users will require, for each site, list, or library where you break inheritance. If your Active Directory administrators are expected to maintain the memberships of these groups, that also means that anytime a Site Collection or Site owner needs to grant or modify a users access to information within the site, this will require a ticket to be placed with IT to make the change. This can have a very detrimental effect to fluid collaboration, the cornerstone of what SharePoint is supposed to bring to your organization.

As a user focused product, the management of access rights to SharePoint content really must fall to the owner of that content, be it the Site Collection Administrator, Site Owner, etc. The user who owns, or is responsible for, the information within a Site should also then be responsible for assigning who has what access to that information. This stipulation should also then drive the taxonomy of your SharePoint deployment. If the content requires a different set of permissions, it should be in a different site. That said, training is an important aspect of any SharePoint deployment as Site Collection Administrators and Site Owners should be trained on the proper methods for granting users access to the information contained within their sites.

Chapter 6 of the SharePoint Best Practices book (Microsoft Press, Ben Curry and Bill English) has a good description of some of the issues that can arise when trying to control SharePoint access from a central team. This section also includes a list of the pros and cons around using SharePoint groups vs. Active Directory groups for assigning access permissions in SharePoint. (Another long standing debate in SharePoint deployments.) There are good reasons to use both of these methods to grant users access to SharePoint resources, but in each case, that association should be done by the people responsible for the content, and not the individuals responsible for the rest of your network. SharePoint is designed to be used, managed, and populated by the community that uses it, your users. Train them and let them collaborate.

Create Multiple Profile Import Connections to Active Directory

Daniel Galant — Mon, 30 Mar 2009 18:29:00 GMT

If you have been working with SharePoint you likely have also been dealing with user profiles and trying to get that user information from your Active Directory into your SharePoint data store so it can be searched, indexed and used. While working with getting this information into SharePoint from AD you may have also discovered that you end up with profile data you really didn’t want or need. If you simply configure your profile connection to pull from the Active Directory domain, you end up with all of your user accounts being imported. This includes service accounts, disabled accounts, and users you just don’t need to have cluttering up your profiles. In an earlier post, Filter those User Profile Imports, I show you how to create filters to only import the accounts you want into your SharePoint deployment. However, filters can be complicated and time consuming to construct. What if you already have your Active Directory setup with the user objects you want located in various Organizational Units. Why not just create different import connections to these OUs and grab just those users?

Well, as I mentioned, if you’ve been working with SharePoint you may have already discovered that it’s not quite that easy. First of all, SharePoint will only allow you to create a single connection to any given Active Directory name space. Now there is a little work around for this that will actually let you create a second connection to the same AD. If you create your first connection using the DNS name of the domain, you can create a second connection using the NetBIOS name. SharePoint will then create the connections and not complain. For example, if your Active Directory is trainsbydave.com with the NetBIOS name of TRAINSBYDAVE, you could create one connection for the name space using TRAINSBYDAVE and a second connection using trainsbydave.com.

This is fine, if all of your users are in one of two OU hierarchies. But what if you have a truly diverse Active Directory and need to connect to several OUs within your organization in order to grab all of your SharePoint users? Welcome to today’s topic. Let’s look at our sample AD – we start with a single OU that contains all of the users we want imported into SharePoint.

The connection for this would look something like the following,

And the results would be,

So how do you make those other connections? The first thing you need to remember is that AD is, at it’s heart, an LDAP directory. SharePoint allows you to create connections to other LDAP directories to import data. So why not just connect to your AD as LDAP? Bingo. In order to create an LDAP connection to Active Directory, you need to provide a few pieces of data. In this example I’m going to use a second OU in the Trainsbydave AD called Corporate from which to import additional users into SharePoint.

Here you can see that there are a few users in the Corporate OU that we want to import into SharePoint. To begin, you need to create a new import connection. You create your import connections from the User Profile and Properties page of your Farms Shared Services Provider application. Under the Profile and Import Settings section select the View import connections link.

Next you’ll select the Create New Connection link.

On the properties for your new connection you can see that there are actually several options for the type of connection that can be configured. Since we have already setup a connection to the Active Directory namespace, let’s use the LDAP Directory option to connect to our other OU.

To create this connection you are now going to need to provide some information to define the properties of the new connection. The Connection name is simply to identify what it is you are connecting to as seen in the Import Connections list. This name can be whatever you would like it to be, but make sure it is descriptive of the connection you are creating. In the directory service server name you’ll want to provide the Fully Qualified Domain Name (FQDN) of one of your AD domain controllers, leaving the port set to 389. For the provider name simply enter “LDAP” and change the username attribute to read “distinguishedname”. For the search base you’ll want to enter the Distinguished Name (DN) of the OU you are importing the users from. Looking back at our AD structure for the Corporate OU the DN for this object would be “ou=Corporate,dc=trainsbydave,dc=com”.

One of the tricks is to be sure and change the user filter. As seen below it is currently set to (&(objectClass=inetorgperson)).

To grab your user objects this filter needs to be changed to the correct object string. For Active Directory this would be the user class of the person object category, so the filter would be formatted as (&(objectCategory=Person)(objectClass=user)). Of course, you can always format the filter as needed to pull only the specific user objects from the OU as needed. For more information on these filters please check out my earlier post Filter those User Profile Imports as mentioned earlier in this blog. The remainder of the connection settings can be adjusted as needed, but the defaults should be fine in most cases. When you finish, your connection settings should look something like this,

Once you have the connection configured, save your settings. This will return you to the Import Connections screen where you will see your new connection.

Now you simply need to perform an Import and grab your additional users. You’ll notice that the number of profiles has increased from 15 to 19, having added the four additional users from the Corporate OU.

Using this method you can create any number of connections to the same Active Directory domain name space and have greater flexibility in your User Profile Imports. I hope that you find the above information useful and if you have any questions, please leave me a note. Until next time….

Filter those User Profile Imports

Daniel Galant — Thu, 05 Mar 2009 00:21:00 GMT

Often times when importing users from our Active Directory domains into SharePoint we simply configure a standard connection and let the import roll. The problem with this is that we end up with a lot of accounts floating around in our SharePoint that we neither need nor want. Service Accounts, disabled user accounts and such are just as much "users" as our active "I need access" users are. So how can we setup the SharePoint profile import to only pull those accounts that we really need into our SharePoint deployment and filter out the riff-raff and chaff?

LDAP filter queries provide the answer to most of our problems, when properly configured. It is best to set these up before you ever perform that first import as this will save you from having to clean out the unwanted profiles that were pulled over the first time. But even if you have already made the initial pull, setting up filtering will keep them from coming back once deleted.

Before we can configure an LDAP filter you need to understand a little bit about how these filters are constructed and some of the options that you have at your disposal. To begin with, there are a few operators that can be leveraged within a query to control how and what is compared within the query itself.

The "!" means NOT as in !apples (not apples).

The "&" means AND as in (&(peanut_butter)(jelly)) (peanut butter and jelly).

The | means OR as in (|(this)(that)) (this or that).

The "=" means EQUALS (IS) as in right=right (right is right).

Next, you need to be able to inform the query of the type of object you are looking for. Since you are generally trying to import User information for your SharePoint profiles, this part is relatively simple. You want to find the User class of the Person object type so we tell LDAP to look for objects where the Category is person and the Class is user. This is then formatted as (&(objectCategory=person)(objectClass=user)). Do you see how we take the question and then format it into the query?

At this point if you were to simply pass this question on to Active Directory you'll end up with exactly what you don't want, all of your User objects. So now you need to add some of the conditions that are available to refine the question somewhat. Let's say you have created all your Service accounts with a last name of Service to distinguish them in your Active Directory. LDAP refers to the last name attribute as the Surname (sn), so we rephrase our question to be:

I want all the objects where the category is person and the class is user but where the last name is not Service.

This would then become: (&(objectCategory=person)(objectClass=user)(!sn=service)).

You can also use the * as a wildcard if you need to. In this example, what if some of your Service accounts use Service as the last name, others have a first name (givenName) that start with SQL (SQLsa, SQLconnect, SQLuser, etc.), or MOSS. In this case the question is a little more complicated but still doable.

I want all the objects where the category is person and the class is user but the last name is not Service, or the first name does not start with SQL or MOSS.

This would then become (&(objectCategory=person)(objectClass=user)(!(|(sn=service)(givenName=sql*)(givenName=moss*)))).

Notice in this case we first group all the NOTs into an OR condition, (NOT(OR(item1)(item2)(item3))). This is telling the query do not take item 1,2 or 3.

Wonderful as this might be, how do you handle all those normal user accounts that are simply disabled? They don't have a common first or last name or even any character in common that wouldn't also exclude any number of truly active users. That's a great question. Well, they do have one attribute in common, they're disabled. To exclude these accounts you can add a condition to also exclude accounts that are disabled. The condition for this is:

(!(userAccountControl:1.2.840.113556.1.4.803:=2))

so adding this into our earlier statement we get:

(&(objectCategory=person)(objectClass=user)(!(|(sn=Service)(givenName=sql*)(givenName=moss*)(userAccountControl:1.2.840.113556.1.4.803:=2)))).

As you can see, it is possible, with a little planning, both in your Active Directory naming convention and the SharePoint import filter, to pull only the Users that you need into your SharePoint profile store. Unfortunately it is not possible to use an Active Directory OU as a filter parameter for the LDAP query, that would make things even easier. Instead, you can create multiple connections into your AD to pull from different OUs. I'll show you how to do this in another post coming soon.

SharePoint - Back to Basics

Daniel Galant — Tue, 24 Feb 2009 22:35:00 GMT

As more and more folks start turning to SharePoint as their solution of choice for information distribution and collaboration, I have been noticing that many of these installations seem to have been quick, no research installations. A number of these installations suffer from common mistakes that are then made by well intentioned, but over-worked and under trained Administrators. In an effort to help stem the tide and perhaps save one or two of you the trouble of having to redeploy SharePoint in an effort to fix an unsuccessful roll-out I'd like to take a trip back to the basics.

First of all, if you are reading this then you are indeed a step ahead of those who did not take the time to do at least a little bit of research on how to properly deploy SharePoint before inserting the CD and hitting OK. With a little planning and forethought you can avoid many of the common mistakes that plague the first time install.

Step 1: Do not use your own personal account when installing SharePoint onto your servers. The account that is used to do the actual binary installation of the SharePoint files is going to own those files and have certain privileged access that, for tighter security, really shouldn't be your user account. Furthermore, do not use a local user account, the local system account or a network system account for the installation of SharePoint binaries on your servers. SharePoint can scaled out into a distributed server deployment and local accounts simply will not provide you the access rights you'll between servers. For this part you are going to want to create a basic user account in your Active Directory domain that you will use for the installation process. This account does not need to be a Domain Administrator, an Enterprise Administrator or even a Server Admin. It simply needs to be a member of the local Administrators group on your SharePoint Server systems. In addition to this you also need to grant the account DB Creator and Security Admin rights on the SQL server that will function as the back end database for your SharePoint deployment. That's it.

Step 2: When performing the installation you will be presented with a couple of different options. the first of these choices will be to select between a Basic or an Advanced installation. This one is easy, always choose Advanced. Always. A Basic install will use SQL Express on the local system as your database and therefore limit the size of your SharePoint deployment. Also, you will not be able to expand your Basic install in the future by adding additional servers should you want to grow your SharePoint farm. The next option you will be presented with will the type of server installation to perform for your Advanced choice. These options include Complete, Web Front End and a Single Server install. Guess what, this really isn't much of a choice either. Always perform a Complete installation. Always. The Single server option is the same as the Basic option from the previous screen and so has the same limitations. Choosing the Web Front End option will limit your flexibility in the future if you should want, or need, to move roles between servers, or worse, need to compensate for a failed system. Save yourself from future headaches and just perform an Advanced>Complete installation every time.

Step 3: Once you have installed SharePoint, making sure you used the account you created in step 1, you will then run the SharePoint Products and Technologies Configuration Wizard. This is where you will actually create your Farm and establish your Central Administration Web Application. During this process the wizard will prompt you for the Database Server, Database Name and the credentials of an account that will be used for the Central Administration Application Pool. At this point you should once again supply the credentials of the account that you just used to actually perform the installation, the one you are currently logged onto the machine as running this very wizard. Yup, the installation account and the Central Administration service account really should be using the same account. This will help you down the road if these two accounts are indeed the same account. It has been my experience that when using different accounts for these two functions, odd behaviors can creep up in your SharePoint world.

Following these few simple steps can save you a number of headaches down the road while working with SharePoint and help get you off on the right foot. I realize that many over-stressed network folks simply don't have the time to get any proper training before having to roll out a product such as SharePoint. Still, before you get to deep into such a project I highly recommend that you at least grab yourself a good book to keep by your side while deploying. One such tome I feel should be by the side of every SharePoint Administrator is the SharePoint Best Practices book by Ben Curry and Bill English.

Until next time...

Customize the NewForm aspx

Daniel Galant — Thu, 19 Feb 2009 17:31:00 GMT

Have you ever wanted to change the fields presented in a form when you create a new announcement or task for your SharePoint team site? Do you wish you could remove a field or two in order to keep someone from changing important metadata once a document has been uploaded into your library? Perhaps you would simply like to expose different fields to different users when editing information in a document library or list. Well, follow along with me now because I’m going to take you on a short journey and show you how to do just these very things.

Hello, my name is Daniel A. Galant and for the past several months I have been employed as an instructor with Mindsharp, the SharePoint people. One of the questions that keeps coming up in our sessions is “How can I change the default new item or edit forms to present only the data fields I want certain user groups to be able to modify?” To begin, let’s take a look at just what it is we are trying to change.

When you want to enter a new item into, let’s say, your announcements list, SharePoint calls upon the NewForm.aspx page for that list, in this case, announcements. The page contains a customized List Form Web Part that displays default columns associated with the Announcements list properties. The New Item form cannot be edited within the browser, so in order for us to accomplish what we want to do, we will need to call upon our trusted companion tool, SharePoint Designer 2007.

To begin our modification journey let’s start by opening up a team site in the browser and taking a look at the default New Item page that we have to work with. Figure 1 shows the home page for the Technical issues team site that we will be modifying.

Figure 1: Technical Issues home page

By selecting the Add new announcement link we are presented with the standard Announcements: New Item page (Figure 2) for adding announcements to our list. Note the columns that are currently available for data entry: Title, body and Expires.

Figure 2: Announcements: New Item page

To modify this page we must open it in SharePoint Designer 2007 and then add a new custom List Form Web Part that displays only the fields that we wish our users to modify. Start Designer and then connect to the website that contains the list whose form you wish to modify, in our case that would be the Technical Issues Team site as shown in Figure 3.

Figure 3: Technical Issues site loaded into Designer 2007

Next we need to open up the relevant NewForm.aspx page. In the Folder List expand Lists and then expand the list you want to work with. Again, we are going to modify the Announcements list so expand Announcements and select NewForm.aspx.

Figure 4: NewForm.aspx in the Announcements list

As you can see in Figure 5, the Announcements: New Item page contains a customized List Form Web Part that will display the fields we noted earlier when we opened the page in the browser. While we can edit the properties of this particular web part, we cannot edit the contents, nor do we want to delete the web part from the page as this can break the NewForm.aspx page and cause it to error out when you try to actually use it in your site. Stick with me because we are going to cover how to deal with this as we go though this tutorial. For now, we want to add some space below the current web part so that we may add our own custom list form to do with as we like.

Figure 5: The default NewForm.aspx page

Select the area just below the current list form and press Enter twice to give yourself some room to work with. Next, to add our custom list form go to your tool bar and select Insert>SharePoint Controls>Custom List Form.. as shown in Figure 6.

Figure 6: Add a new Custom List Form

Selecting the Custom List Form will bring up the List or Document Library Form dialog shown in Figure 7 where we need to choose which list we are tying this new web part to as well as the type of form we want to create. In our example we are keeping the default Announcements list since we are creating a new Announcements form as well as selecting the New item form radio button because we want to use this web part to create new announcements for our site. If we were going to modify the web part for a different document library or list within our site we would need to choose that library or list from the drop down menu. If instead of creating a new item, we wanted to use this form to edit an already existing item; we would select the Edit item form radio button instead.

Figure 7: List or document library selection dialog

When finished you should have your new list form web part as displayed in Figure 8.

Figure 8: Newly added List Form web part

As mentioned earlier, the form we are using is pulling its data fields from the columns that are defined in the list or library that we are connecting the web part with. What if we want to create our own columns or collect information about items that are not currently part of the list or library? To do this we would need to add additional columns from already existing Site columns or simply create our own to suit our needs. To accomplish this task we must venture into the settings of the list or library that contain the items we want to collect or modify data from.

We’ll start by selecting the View All Site Content link at the top of our Quick Launch menu at the left hand side of the browser window. This will bring up the All Site Content screen as seen in Figure 9. Next we must select the list we are working with, in our case that would still be Announcements.

Figure 9: The All Site Content page

Once you are in the list or library that you want to add information to, select the Settings menu and then select List Settings, (Figure 10).

Figure 10: List Settings menu option

On the settings page for your list or library you will see a section titled Columns, (Figure 11). It is here that we can add columns from the already defined site columns in SharePoint or create a new column to collect whatever data we need for the items in our list.

Figure 11: Create or add new columns section

When you have defined the metadata types that you wish to collect on your list items, we need to make those columns available in our new List Form Web part. To do that, we’ll go back to SharePoint Designer 2007 and add the form elements into our new form.

In the Toolbox task pane you’ll notice a section labeled SharePoint Controls (Figure 12). If the Toolbox is not visible in your Designer, go to the Task Panes menu item and select Toolbox. Expand the SharePoint Controls and you’ll see the various elements that can be inserted into your form to allow you to collect the data that is relevant to your list items. These elements directly map to the column data types that are defined when you add or create a new column in any library or list within SharePoint.

Figure 12: SharePoint Controls in the Toolbox task pane

Select the data view control that maps to the type of field whose data you wish to collect and drag it from the toolbox and drop it into your new list form. This will bring up a control dialog in which you will map the control to the column in your list whose data you are interested in. You’ll notice in Figure 13 that we dropped a text box into our form and we are going to map it to the Modified By field in our Announcements list.

Figure 13: Mapping a list field to a data view control

Next we merely give our new control the proper label, (Figure 14) and then save our new NewForm.aspx page.

Figure 14: Adding the label for our control

Since we are modifying the default page you will receive a warning (Figure 15) that the page is being altered from the site definition. Select Yes to save the changes.

Figure 15: Site definition warning dialog

Now we can view our new New Item page in the browser and see just what we have done. As you can see in Figure 16 there are now two list form web parts on the page; our original web part with the default configuration of fields, and our new web part with its modified content.

Figure 16: New Item page with two list forms

Since we want to present only a single form for our users to fill out, with only the items we have selected for them to modify, we must hide the original web part on the page. To accomplish this we again return to Designer 2007 and the NewForm.aspx page we have been working with.

Select the original ListFormWebPart and hide it by right-clicking and selecting Web Part Properties from the popup menu. (Figure 17)

Figure 17: Selecting Web Part Properties popup

In the Announcements properties expand Layout and check the box for Hidden (Figure 18). Again, we don’t want to delete the default web part since this can break the page and cause it to error when trying to load within SharePoint. Remember to save the new page.

Figure 18: Hiding the default Announcements web part

We now have our Announcements: New Item page that only displays the elements that we want to expose to our users as seen in Figure 19.

Figure 19: The new Announcements: New Item page

Using the principles shown here you can create a form to display any of the content columns that are associated with your lists and libraries in your SharePoint deployment. But what about exposing different columns to different sets of users? By applying what we have learned here you can create separate web parts that expose only the columns you want exposed for each set of users and then apply audience filtering to make them accessible to the proper groups.

So what about removing elements from the Edit Item form so that metadata isn’t improperly changed when a user edits the properties of an existing document? Let’s take a quick look at the Edit item page for a document library where content types are enabled. Notice in Figure 20 in our Problem Reports library App Crash document properties there is a field to select the content type that is associated with this document. A misinformed user could potentially change the content type associated with this document and thereby change the metadata or even workflow's attached with this document type.

Figure 20: Edit Item page showing Content Type selection box

To prevent this situation for occurring we need to modify the default EditForm.aspx page that is associated with this document library. To do that we need to use Designer, just as we did when modifying the NewForm.aspx page earlier.

Start by connecting to the site that contains the document library (our Technical issues site) and then locate the library you want to work with (Problem Reports in our case). Expand the library and you will see the associated forms as shown in Figure 21. This time we want to modify the EditForm.aspx page so open it with Designer.

Figure 21: Selecting the library to work with

Now just as we did with our previous NewForm.aspx page we need to add a new list form web part to the page and hide the existing default web part from our users. This time, however, when we insert our new web part we must be sure to connect it with the proper library (Problem Reports) as shown in Figure 22 and then select the proper form type (Edit item form) that we are creating as shown in Figure 23.

Figure 22: Connecting the form to the proper library

Figure 23: Configuring the List Form Web Part

From there it is simply a matter of configuring the field types, adding the proper SharePoint controls and saving our page. Figure 24 shows the modified Problem Reports library Edit Item page without a content type selection box.

Figure 24: Edit Item page without the Content Type selection box

So there you have it. You can now modify your default forms to display just the fields you want them to while hiding the ones you need to. I hope you have found this tutorial useful and if you should have questions or comments, please let us know. Till next time…