sharepoint.H@ck

Here is a nice one:

Problem:

• User has a property changed in AD (like surname when married)
• Changes do not reflect in SharePoint 2007 when you view the user

Troubleshooting and Solution:

• First check that none of your content databases are in “offline” mode, if they are then changes will not be able to be written to them.
• Check that you are not having any synchronization events in the event log, this can happen if you previously moved a content database to another Web Application / moved SSPs without running the stsadm –preparetomove command.
  • This is no longer necessary after the Infrastructure Update / SP2
• If you are still having the issue, then you can run the new stsadm –o sync ingoreisactive 1 command, this will force a fresh update on all profiles
  • This is only available to SharePoint 2007 builds 12.0.6314.5000 and upwards.
• Once done, perform a full user profile import and the changes should now reflect

Alternative Solution:

• Create a test account
• Migrate the problem account to the test account using: stsadm –o migrateuser –oldlogin domain\problemAccount –newlogin domain\testAccount
• Migrate the testAccount back to the old problem account: stsadm –o migrateuser –oldlogin domain\testAccount –newlogin domain\problemAccount
• Done.

Regards,

Doug “bobTheBuilder” McCusker

Here is an interesting “gotcha!”: When migrating a user who also happens to be the sole site collection administrator for a site collection (this means that no secondary site collection owner has been specified), you may find that after migration you are no longer to administer the site collection, although users can still browse it.

When you try to view the site collection administrators group you get a horrid “User not found” error message in the UI / “Error: Unable to find user” message when running the stsadm –o enumsites command.

Solution:

• DONT PANIC!
• Simply specify the new site collection owner through the stsadm –o siteowner –url http://SiteCollectionURL –ownerlogin domain\newUserLogin

Proactive Solution:

• Always ensure that each site collection has both a Primary and Secondary site collection owner

Regards,

Doug

Got to love SharePoint 2007, you learn / encounter something new everyday :)

I recently got a request to help resolve an issue with a missing root site collection after a backed-up content database attach procedure. What happened was that the user had created a web application to attach the backed-up content database to, when they attached the content database and browsed to the root site they did not see the content they expected.

What caused this is as follows:

• Person created site collection at root level of new web application.
• The backed-up content database to attach ALSO had a root site collection.
• When the user attached the backed-up content database it left out (not deleted) the root site collection in that content database.

What fixed this is as follows:

• User removed content database created with new web application.
• User removed backed-up content database from the web application.
• User re-attached the backed-up content database
• Voila!

How to avoid this in the future:

• When creating a web application to attach a content database to, don’t create a root level site collection :)

Regards,

Doug

So the other day I felt like a real chop as I “assumed” something was done while I was setting up Kerberos, we all know that assumption is mother of all youknowwhats. So here I have put together a “Kerberos Checklist” which should help to troubleshoot the main issues related to the setup of Kerberos in your SharePoint 2007 environment.

Check list here

 

Hope this helps :)

Regards,

Doug

For those of us who like to play around with virtual machines and find ourselves unable to to load a guest 64-bit OS without the wonderful Hyper-V or some other costly solution, there is HOPE!

I stumbled across VirtualBox, a FREE VM environment that allows you to run a x64 guest OS on any host OS. Check it out here: http://www.virtualbox.org

I am currently running one at home on my Windows 7 box :)

Note: I only recommend this for those who like to dabble on their machines at home as I have no idea how it would it perform in a production environment. What I have noticed is high (but no too high) CPU utilization on the host machine.

Regards,

Doug

from www.sharepointhack.net:

Earlier I spoke about how you can tell the people-picker control to look up a list from a different domain.

Now what happens if you need people-picker to look up users from two different domains and each domain has a separate account that needs to be used to view users?

The answer is quite simple; you can append another domain with a separate user account to the "stsadm -o setproperty -pn peoplepicker-searchadforests" command:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domain1.com,domain1\account1,password1;domain:domain2.com,domain2\account2,password2 -url http://url.com

Note the semicolon between the two domains :)

Hi, I have registered www.sharepointhack.net where I will be posting new information (which will be copied here). Why? I need some more space to upload files and I like the domain ;) Regards, Doug

Note to all of those out there that are using / planning to use Kerberos authentiction in your SharePoint 2007 environments: if you have applied the Infrastructure Update you will need to modify the registry to support new SPN naming conventions and then add these SPN accounts to the SSP service account. Details can be found here: http://technet.microsoft.com/en-us/library/cc263449.aspx#section14 As if we did not need more steps to configure Kerberos ;) Regards, Doug

So you have successfully imported all the AD users into MOSS and can search them fine, now you have a problem where you are not able to see all of these users in the people-picker.

One of the main causes of this is that when you specified the AD connection, you were required to use a separate account as the farm account did not have access to traverse the relevant AD forest / domain.

Another reason this can happen is that your MOSS servers belong to a separate domain as the AD user domain.

You would think that the people-picker would use the user profile store / use the same account specified in the AD connection, well it actually uses the farm account to connect to AD. You may often see only some users and this is because those users exist in the same domain as the MOSS server.

Don't panic! This is actually quite easy to fix with a standard stsadm command, be aware though that you will need to execute this on every WFE in the farm AND for each web application.

INSTRUCTIONS:

If the AD domain has a 1-way trust and you need to specify a username and password, execute the following commands on every server in the farm:

• stsadm –o setapppassword –password MyPassword (ensure you use the same password for each server you execute this command on!)
  
• On every WFE in the farm execute the following command to instruct the people-picker to use the corret AD domain:
  
  stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:YourDomain.com,domain\user,password –url relevant web application (you need to run this for each web application, if you do not run this on the WFE you will see a “callback error” in the people-picker)
  
  Note: you can specify mulitple domains to lookup as well, just encapsulate the domain names in quotation marks and seperate them with a semi-colon (-pv “YourDomain1.com;YourDomain2.com”,domain\username,password)

If the AD domain has a 2-way trust you do not need to run the stsadm –o setapppassword command, just execute this one:

• stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:YourDomain.com,domain\user,password –url relevant web application (you need to run this for each web application, if you do not run this on the WFE you will see a “callback error” in the people-picker)

RESET :)

If you need to reset the people-picker back to normal, just execute this command:

• stsadm -o setproperty -pn peoplepicker-searchadforests –pv (don’t specify anything here) –url relevant web application (you need to run this for each web application, if you do not run this on the WFE you will see a “callback error” in the people-picker)

Hope this helps anyone out there.

Doug “bob-the-builder” McCusker

Ok, so setting up keberos for MOSS on Windows Server 2008 and SQL 2008 is somewhat different from how you would set it up in earlier versions. This post lists the “gotcha” you should be aware of rather than step by step instructions on how to configure everything (if you set up Kerberos before you will know what to do). The Windows Server 2008 portion is from the brilliant mind behind harbar.net :)

SQL Server 2008:

If you are following the least privileged method for your MOSS accounts you will need to give your MOSS Install account the new “setupadmin” permission on the relevant SQL Server 2008 Database – you don't want to know what I went through to discover this!

Windows Server 2008:

Taken from (harbar.net): One of the security changes in IIS 7.0 is that Windows Authentication is performed by default in the kernel. This is a good thing! It eases the configuration required for Kerberos and improves performance significantly.

Because HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool identity. This means that the creation of an SPN is unnecessary because default SPNs are created when the server is joined to the domain. You can of course change the app pool identity without having to register a SPN, and the app pool account doesn't need to be a domain account.

However, it trips up SharePoint as even on a single server SharePoint is currently considered a web farm (should use a domain account). Therefore you need to use the application pool identity for authentication.

The recommended way of doing this:

• Configure the useAppPoolCredentials attribute in system.webServer/security/authentication/Windows-Authentication configuration section to true. For example:
  
  <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />

When deploying content through content deployment jobs you may want to check how much space you have available.

Not so well documented is the fact that content deployment jobs will require you to have some space available on the drive where the account running the SharePoint Timer service has its local temp folder (in the user profile). I only realised this today when investigating a content deployment failure, what happens during a content deployment is the following:

• Timer collects the content deployment data from SQL and stores this in the accounts temp folder (usually in the c: if you have not change environment variables)
• Data is then extracted and dumped in the folder specified as the content deployment folder in Central Admin.
• Extracted data is moved to the content deployment folder on the target machine.
• Timer on destination machines extracts the data to its local temp folder and dumps it in SQL

Wow, lots of space needed and if you have not changed the envrionment variables, this may casue some space issues on the servers.

Now what I found interesting is that the user profile temp folders were not being cleared out after this whole process - OUCH, better create a scheduled task to clear this out.

• This may be due to the failed deployment job - so double check. In fact, even if it is because of this that means content for failed jobs is still hanging around.

Some Ideas:

• If you are installing a clean environment, be sure to change the environment variables for the account that will be running the SharePoint Timer service.
• In existing environment, try changing the temp folder location in the reg (HKEY_USER)

An event you may encounter:

The following event description may crop up if there is not enough space left to uncompress the deployment files:

"Failed to read package files"

• You will also see it in the deployment job failure message

Regards,

Doug "bob the builder" McCusker

 

This is something I have been wanting for a while and I finally managed to get it right :)

Scenario:
You want to be able to create a default publishing page that contains a pre-configured content query web part that rolls up information from the current web location. This is can be usefull for instance if you would like to display a summary rollup of specific pages within the site and mabye even have a list of all the pages in the site as a navigational item on each content page.

Problem:
The problem with the standard content query web part is that a user has to manually set the web location of the content that they want rolled up. If you try add it to a layout page then each page created will always show content from the web location that was defined / all sites in the site collection, regardless of where in the hierarchy the page is sitting.

Solution:
I created a custom content query web part called "What Web Content Query" (hey, I am no good at naming things, we all know this) that inherits from the default content query web part, but overrides the "WebUrl" setting with the site path in the current URL. You will not believe how handy this has come in :)

Build It:
So, here is how you build it:

• Open Visual Studio 2005 / 2008
• Create New Project -> C# -> SharePoint -> WebPart
• Add a new reference to "Microsoft.SharePoint.Publishing.dll"
• Use my code sample below to modify the contents of your .cs file (the important stuff is in orange):

using Microsoft.SharePoint.Publishing.WebControls; //Need this reference for the ContentByQuery web part

namespace WhatWebCQWP
{
    [Guid("03b0b57c-6607-44f5-adfd-b361d6129687")]
    public class WhatWebCQWP : ContentByQueryWebPart
    {
        public WhatWebCQWP()
        {
            this.ExportMode = WebPartExportMode.All;
        }

        protected override void CreateChildControls()
        {
            Uri WebLocation = new Uri(SPContext.Current.Web.Url); //Replace the default web location property of CQWP with current URL
            this.WebUrl = WebLocation.AbsolutePath.Replace("%20", " "); //Get only the absolute path and replace encoded space with unencoded space
            base.CreateChildControls();
        }

        protected override void RenderWebPart(HtmlTextWriter output)
        {
            base.RenderWebPart(output);
        }
    }
}

Once you have built the web part and deployed it to your farm you may want to know how to add it to your layout page:

• Create a new layout page.

• In SPD, drag the web part onto yout layout page (I would also recommend that you add the web part itself outside of a web part zone template, like the Summary Links web part)

• Save and create a page based on your new layout somewhere.

Sweet. Now I have not gone in to heavy detail, this should be enough for all the smart people out there to follow :) What you may want to do is look at including custom item styles and specific fields that you want displayed - go HERE: http://www.heathersolomon.com/blog/articles/CustomItemStyle.aspx

 

Regards,

 

Doug "bobthebuilder" McCusker

For those who don’t know, this sweet stsadm extension allows you to copy content types and columns from one site collection to another, regardless of web application:

 

http://stsadm.blogspot.com/2007/08/copy-content-types.html

 

Perfect for consolidation projects. From the awesom mind of Gary Lapointe http://stsadm.blogspot.com, kudos mate.

 

Had to share, could not keep it to myself :)

 

Regards,

 

Doug "BobTheBuilder" McCusker

I feel bad, have not blogged for a while now; to friggin busy it seems.

Anyway, I found quite a nice little "trick" the other day when looking at a CMS 2002 migration to MOSS 2007. Previously the all pages of a certain type had the contact details of the person who was responsible for the information on the page as indiviual controls:

• Name of Person
• Telephone of Person
• Email Address of Person

Authors had to type these details in individually, so I thought to myself "there has to be a way to include user profile information, where the author can use the people picker like in a nomal list item"; not so easy to find it seems.

To cut a long stroy short what I did to include the people picker on the layout page was to do the following:

• Added a new column to the relevant page content type which was a user/group column: lets call it "ContactPicker"
• Opened the layout page in my favorite editor (notepad hehe) and added the following piece of code: <SharePoint:UserField id="1234" FieldName="ContactPicker" runat="server" />
• And bobs your uncle, authors are now able to select a user and viewers are able to see the contact details for the page (which get updated from AD / FBA).

What is interesting is that I have yet benn unable to find any documentation around using the <SharePoint controls in a layout page, everyting points to using the <PublishingWebControls, there are a bunch that you could use - if anyone out there has more clarification, please share :) The way I worked it out was: "hey, lets try this".

Regards,

Doug "BobTheBuilder" McCusker