|
Mar
31
Published: March 31, 2010 10:03 AM by
Daniel Galant
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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
Powered by: Mindsharp and Summit 7
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….
Mar
05
Published: March 05, 2009 00:03 AM by
Daniel Galant
Powered by: Mindsharp and Summit 7
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.
Feb
24
Published: February 24, 2009 22:02 PM by
Daniel Galant
Powered by: Mindsharp and Summit 7
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...
|
|
|
|
|