Unable to authenticate + crawl errors on MOSS on Windows Server 2008

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 01-12-2009

If you’re having some of the following symptoms:

1. You’ve created a web application and you’re sure that credentials are right, but you’re unable to login to the site collection in that web application.

2. Search index log returns strange errors about not finding the web application or access denied.

Then the solution is in the following article:

http://support.microsoft.com/kb/896861 

This did the trick for me:

  1. Start regedit
  2. Open key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  3. Create a new multi-string value called "BackConnectionHostNames"
  4. Type web application’s host name(s) in the Value Data box.

Save and close regedit. Then using Services under Administrative tools restart the IIS Admin service

Interactive stsadm help

Filed Under (MOSS, SharePoint, SharePoint administration) by Boris Gomiunik on 07-06-2009

At TehNet they’ve released a very nice silverlight interactive help for STSADM command which the SharePoint Admin almost can’t imagine living without.

Straight to the point:

stsadm for MOSS 2007
http://technet.microsoft.com/en-us/office/sharepointserver/cc948709.aspx

stsadm for WSS
http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd418924.aspx

Limiting the People picker and profile import from AD to certain group

Filed Under (MOSS, SharePoint, SharePoint administration) by Boris Gomiunik on 02-06-2009

If you have a SharePoint environment which not every employee in the organization uses you’re stuck with two obsticles:

  1. How to limit that the person is not selected and/or added as a member of the site collection (because of licencing issues)
  2. How to stop MOSS from importing entire AD domain or forest. If you’re stuck with 100 users from 1000 to enter information manually can be a pain.

The solution can be that SharePoint will not recognize other domains/forests than the ones specified and limit the people from those forests to only certain groups.

Here’s what I did. Let’s say we have an AD domain called contosio.local. In this domain We’ve created OU called AccessGroups and in this OU we’ve created a security group called SharePoint. We want to do this for the site http://moss

1. To limit People picker to certain group in AD domain
a. limit the peoplepicker property only to specified domain by running the following command
stsadm –o setproperty –pn "peoplepicker-searchadforests” –pv “domain:contosio.local,contosio\administrator,adminPassword” –url http://moss

Note in the example above you have to enter the account with the right to read from AD and its password. If you want to limit the access to multiple AD domains, separate the values in pv with semicolon.

b. limit the peoplepicker property to custom LDAP filter by running the following command:
stsadm –o setproperty –pn peoplepicker-searchadcustomfilter –pv “(memberOf=CN=SharePoint,OU=AccessGroups,DC=contosio,DC=local)” –url http://moss

Now you’ll be able to add people only from the domain contosio.local – group SharePoint. Don’t forget to add users to security group.

2. To limit profile import only to that same AD group (MOSS ONLY)
a. Open SharePoint Central Administration
b. Open Shared Services Administration
c. Click User Profiles and Properties
d. Click View Import Connections
e. Edit the domain connection for the domain (if you don’t have one yet, you’ll have to create it manually)
f. Change the default value of the field  User filter from (&(objectCategory=Person)(objectClass=User)) to
(&(objectCategory=Person)(objectClass=User)(memberOf=CN=SharePoint,OU=AccessGroups,DC=contosio,DC=local))

Like that you now control from AD who can access SharePoint and who’s profiles get imported.

Edit properties – Access denied error in document libraries

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 25-05-2009

A very interesting symptom occurred to me the past time. In a document library I was trying to edit document properties but I received an error that I don’t have rights. Strange. Even if I tried to edit with a site collection administrator account, I got the same error.

After searching for a while, I’ve found the solution. Looks like a bug that is fixed with February update, but you have to fix the existing bugs manually.

You can find the solution on Social TechNet. Using Visual Studio create a console application and copy-paste the code published there. I’ve made slight modification to the code, because I needed to have this fix in a subsite:

Old code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Xml;

namespace CA_TestingHotfix
{
    class Program
    {
        static void Main(string[] args)
        {
            FixField(args);
        }

        static void FixField(string[] args)
        {
            string RenderXMLPattenAttribute = "RenderXMLUsingPattern";

            //Console.WriteLine("Please enter the URL of the site: (Press enter after typing):");
            string weburl = args[0];

            //Console.WriteLine("Please enter the Document Library Name: (Press enter after typing):");
            string listName = args[1];
            SPSite site = new SPSite(weburl);
            SPWeb web = site.OpenWeb();
            SPList list = web.Lists[listName];

New code (changes marked with bold)

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Xml;

namespace CA_TestingHotfix
{
    class Program
    {
        static void Main(string[] args)
        {
            FixField(args);
        }

        static void FixField(string[] args)
        {
            string RenderXMLPattenAttribute = "RenderXMLUsingPattern";

            //Console.WriteLine("Please enter the URL of the site: (Press enter after typing):");
            string weburl = args[0];
            string subwebUrl = args[1];

            //Console.WriteLine("Please enter the Document Library Name: (Press enter after typing):");
            string listName = args[2];
            SPSite site = new SPSite(weburl);
            SPWeb web = site.OpenWeb(subwebUrl);
            SPList list = web.Lists[listName];

 

After you have the code ready, compile the program, put it on the server and run the command

[programName].exe [http://site_coll_url] [subweburl] [document_library_name]

If you need to run it for example on the top level web see the example below

fixDocLib.exe –url http://testSite:8080 / “Shared Documents”

Fixing / Reattaching / Changing the Lookup list

Filed Under (MOSS, SharePoint, SharePoint administration) by Boris Gomiunik on 19-05-2009

Today the strangest thing happened. During the content migration suddenly the target list lost the proper destination. The result was ALL the lookup values missing and the dropdown empty when adding /editing. Horror! if this would have been a short list the first thing I’d do is to restore it from backup and recover the lookup values. But this being the couple-thousand-records-and-growing-daily list I couldn’t afford that.

With a bit of research into Lookup Field Schema XML I’ve discovered that the LookupList and WebID properties (GUIDS) were wrong. Using SharePoint Manager I could correct the WebID but not the LookupList.

Fortunately after a short period of googling around I’ve discovered this post:

Reattaching LookupList Property to a new List

and that worked like a charm! All the values magically reappeared and lookup dropdowns are back in action.

Links in notification / alert emails corrupt after site migration

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 12-02-2009

If you’ve moved the entire site collection by using stsadm –o backup and restore commands, you might notice that the email notifications either might not work or the links in email notifications might still point to the old URL. This can be resolved simply by using the following stsadm command on the destination server:

stsadm -o updatealerttemplates -url http://[portalnamehere] -filename "C:\Program files\common files\Microsoft shared\web server extensions\12\template\XML\alerttemplates.xml"

This fixed my corrupt links and even restored the nice look of the email.

Upload bug in MOSS 2007 / Windows Server 2008

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 09-02-2009

With the new installation of MOSS 2007 on Windows Server 2008 you might run into a slight bump when trying to upload large files – to be more precise – files larger than 28 MB. Even though you’ve increased the maximum upload limit in SharePoint central administration, the upload still doesn’t work. Here are some symptoms that I received:

  • Page cannot be found error in Internet Explorer when trying to upload to MOSS document library through “Upload” button
  • Document not displaying in document library after uploading with “Upload multiple files” button even though the upload went to 100%
  • Windows delayed write failed when trying to upload document through Explorer view. After the error the file appears in document library, but it has a file size 0.

Read the rest of this entry »

-cabsize 1024 not working

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 02-11-2008

If you’ve been trying to use one of my earlier described methods to migrate a SharePoint site (using stsadm -o export) you might have gotten frustrated, because even if you did use the -cabsize 1024 switch the result was still exported to two or more files with 25 MB size.

image

If we take a look at explanation of -cabsize switch when running the command, we can see the following description: [-cabsize <integer from 1-1024 megabytes> (default: 25)]. Looks like 1024 isn’t included. so if you wish to have the backup in chunks larger than 25 MB, use the

-cabsize 1023 switch.

 image

And that does the trick.

Oznake ponudnika Technorati:

SharePoint Config database Log file too big – reduce it!

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 31-10-2008

SharePoint Config database logs are one thing to keep an eye on since they do have a tendency to grow. If you don’t perform a full farm backup usually the log doesn’t get emptied and it just keeps bloating.

If you’re running SQL Server Express with default installation, you can find the files in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data

image

As we see in the example above, even though the database is only 6 megs, the log file grew to 11 gigs. Let’s reduce that:

1. If you don’t have it yet, download and install SQL Server Management Studio express from here.

2. Run the Management Studio and connect to your SQL Server.

3. Expand “Databases” and select your config database “SharePoint_Config”.

4. Right Click it, select Tasks –> Shrink –> Files

image

5. In the new window select Release unused space and click OK.

image

If that doesn’t decrease the database size much, do the following:

1. First to be on the safe side, let’s back it up (this step is optional)

Select New Query

type the following:

BACKUP LOG [Sharepoint_Config] TO DISK=’D:\configLogBackup.bak’
GO

where SharePoint_Config is the name of your config database file and D:\configlogbackup.bak is the location and file name of where you’ll make the backup.

And click Execute

image

This may take a while if your log file is big.

2. Next clear the query (or click New Query again) and enter the following commands

BACKUP LOG [Sharepoint_Config] WITH TRUNCATE_ONLY
USE [SharePoint_Config]
GO

anc click Execute again

image

3. Clear the query or open another query tab and enter the next command:

DBCC SHRINKFILE (N’SharePoint_Config_log’ , 50) 
GO

The 50 in the command above sets the size in MB to truncate the log to. If your config db is of different name, replace the SharePoint_Config part above with your config db name.

And click Execute yet again.

image

The result you get should be something like below:

image

and ofcourse the file size:

image

ahhh. finally some space.

Oznake ponudnika Technorati: ,

AD Users not recognized in SharePoint?

Filed Under (SharePoint, SharePoint administration) by Boris Gomiunik on 06-10-2008

Not long ago we’ve had a situation where the newly created users in Active Directory couldn’t be recognized to add them in SharePoint.

The whole topology was the following:

1 server as Primary Domain Controller for domain
2 server as secondary Domain Controller for same domain and for hosting SharePoint

Each on its own external line and connected between themselves with VLAN.

The trouble was that the users that were created in AD (on any DC) couldn’t be recognized in WSS. We could add them to SharePoint some 30-180 minutes later.

It turned out that the problem was the firewall between the servers in VLAN. As soon as we fixed that the problem was resolved.

If firewall isn’t the problem, you can also set the secondary DC as Global catalog.

ads
ads
ads