|
Mar
03
Published: March 03, 2011 19:03 PM by
Daniel Galant
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….
Feb
18
Published: February 18, 2011 23:02 PM by
Daniel Galant
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.
Mar
31
Published: March 31, 2010 10:03 AM by
Daniel Galant
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.
Dec
04
Published: December 04, 2009 15:12 PM by
Daniel Galant
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.
Nov
29
Published: November 29, 2009 21:11 PM by
Daniel Galant
On December 12th I’ll be speaking at SharePoint Saturday in Kansas City, (ok, Overland Park actually). With all the great speakers and topics it should be a wonderful day. My understanding is they upped the registration to some 300 folks and that filled up pretty fast. I’ll be showing off what’s new and improved with SharePoint Designer 2010 and hope to see some of you there. Drop in and introduce yourself or just say hello.
Nov
29
Published: November 29, 2009 20:11 PM by
Daniel Galant
Don’t miss your chance to get a look at what SharePoint 2010 has in store for you and your organization. Mindsharp, the leaders in SharePoint education are holding classes this December in both core technologies and development and there are still seats available. Let Ben Curry, author of the SharePoint 2007 Administrator’s Companion and Best Practices books be your guide as you discover what’s new in the 2010 release of SharePoint Server. With a redesigned interface, new features, enhanced social networking, new service applications and more, there is lots to see and discover in this release. For developers, Todd Bleeker, the SharePoint Wizard, will show you tricks and tips, the ins and outs and basically take you deep under the hood of the SharePoint API. Head on over to Mindsharp 2010 Beta Classes for more information and to reserve your seat today.
Oct
20
Published: October 20, 2009 01:10 AM by
Daniel Galant
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.
Jun
18
Published: June 18, 2009 22:06 PM by
Daniel Galant
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.
Apr
10
Published: April 10, 2009 15:04 PM by
Daniel Galant
The very successful SharePoint Best Practices Conference is happening again, and this time it’s expanding. No longer limiting the content to SharePoint, the conference is now simply known as the – Best Practices Conference. This time it will include sessions on SQL Server as well, to help compliment the great information dished out about SharePoint. SQL Server being such an integral part to a successful SharePoint deployment, it makes a good deal of sense to put these two topics together into a single conference to help benefit those IT folks who must manage and maintain SharePoint in their environments. The conference is scheduled to take place at the Hyatt Regency Reston, just outside of Washington D.C. on August 24 – 26. For all the details and registration information go to Best Practices Conference. This has been a very popular, and productive conference so book early to reserve your space.
Mar
30
Published: March 30, 2009 18:03 PM by
Daniel Galant
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….
|
|
|
|
|