RSS

Monthly Archives: June 2009

User can’t view WebParts in MOSS

We had a user that cannot see all the web parts that are available on their site.  They have Full Control of the site.  I see them when I go to the site (but I’m the Site Collection Admin).  The problem is when they try to add a webpart, under All Webparts, he gets “No webparts found” when they should have a list similar to the following: 

 

webpart

The solution to this is to add the user to the root site collection with Read permissions. I know I know, what if you don’t want the user to have Read permissions to the root? Well that’s a question for Microsoft. However, this will fix it and allow work to continue.

 
Leave a comment

Posted by on June 17, 2009 in SharePoint Common Issues

 

Kerberos Authentication in SharePoint

We’re currently using Kerberos in our environment but I have to say it was a little more difficult to get working than I had originally hoped. There is a lot of documentation out there explaining Kerberos authentication and the process in which it should be done but what I had trouble finding were specifics on the account changes that need to be made. Here are the notes I took down from this process. These are specific to our setup but will hopefully be of some help.

Before you even use SharePoint with the intention of authenticating with Kerberos you need to apply the Infrastructure updates to your MOSS installation. There are separate updates for WSS and MOSS so be sure to install both. WSS first then the MOSS update. Kerberos authentication cannot be configured to work with the Shared Services Provider infrastructure otherwise.

You also need to have your server and service accounts set to “Trust this computer for delegation to any service (Kerberos only)” in their Active Directory properties. If you have to have the services trusted for delegation specified like in our case then here are the services you want to trust:

CIFS

DCOM

HOST

HTTP

IISADMIN

RPC

W3SVC

WWW

Once you have the Infrastructure updates applied and your server(s) trusted, you need to have your SharePoint accounts created. Whether you’re using one or multiple accounts they need to be in place beforehand. You must register your Service Principal Names (SPN) before authentication can work. Here are the specific SPN’s  you need registered along with the command line to use. This command will have to be run on the MOSS server itself using adsutil.exe (Administration Script Utility). This is also assuming you already have a domain controller to authenticate to.

This will vary depending on your account set up but I’ll try to generalize them:

(You do not need the “” in this commandline, they are simply to separate items)

For your SQL Service account:

setspn -A mssqlsvc/”servername“:1433 (default SQL service port)

setspn -A mssqlsvc/”servername“.”domainname“:1433 (ex. myserver.mydomain:1433)

For your Application Pool account:

setspn -A http/”mysite URL” “application pool account name

setspn -A http/”site collection URL” “application pool account name

setspn -A http/”servername

setspn -A http/”servername“.”domainname

For your SharePoint admin account:

setspn -A http/”servername

setspn -A http/”servername“.”domainname

For your Shared Services Provider (SSP) account:

setspn -A mssp/”servername“:56737/”SSP name

setspn -A mssp/”servername“:56738/”SSP name” (56737 and 56738 being the standard IIS ports for SSP)

For your SharePoint Search account:

setspn -A http/”servername

setspn -A http/”servername“.”domainname

Anything in bold you will obviously have to put in your own info and if you’re using less accounts then some of these will be combined. You can see the ones that are redundant and go from there. If you’re setting up Kerberos for

Here is a really good article on this if you want to know the specifics of how Kerberos and SharePoint work together.

http://www.windowsecurity.com/articles/Kerberos-Sharepoint-Environment.html

If you have any questions feel free to ask.

 
Leave a comment

Posted by on June 9, 2009 in SharePoint Tips

 

An unexpected error has occurred – SharePoint

We did a fresh MOSS install on Server 2003 SP2 for a development server. Just a complete install using NTLM and a SQL Server 2005 database server. The install ran fine as well as the Configuration Wizard but when it opened CentralAdmin after the configuration wizard ran I got the following:

Unexpected error has occurred

Then I made the following changes since “An unexpected error has occurred” is not as descriptive as it could be:

  1. Edit the web.config file in Notepad for the site Central Administration (C:\Inetpub\wwwroot\wss\VirtualDirectories\….is a number)
  2. Look for “CallStack” in the SafeMode section, change the value from false to true.
  3. Look for “CustomErrors” in System.Web section, change the value from On to Off.
  4. Save the file and close it.
  5. Execute IISReset.

Changing this will give you a more descriptive error so you can troubleshoot the issue easier. Once this was changed we did an IIS reset and went back to Central Admin to get this message:

Server Error in Application

If unreadable:

Server Error in ‘/’ Application

This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

I researched this error and found that it was a common issue with ASP.NET and you could do a workaround for it. Here is the link to the workaround or you can read the copied info below.

**Make a backup copy of your web.config before you edit it**

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

Important These steps may increase your security risk. These steps may also make the computer or the network more vulnerable to attack by malicious users or by malicious software such as viruses. We recommend the process that this article describes to enable programs to operate as they are designed to or to implement specific program capabilities. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this process in your particular environment. If you decide to implement this process, take any appropriate additional steps to help protect the system. We recommend that you use this process only if you really require this process.

To work around this problem, change the configuration in the application-level Web.config file. Specify that ASP.NET use the Triple Data Encryption Standard (3DES) algorithm to process view state data. To do this, follow these steps:

  1. In a text editor such as Notepad, open the application-level Web.config file.
  2. In the Web.config file, locate the <system.web> section.
  3. Add the following <machineKey> section to in the <system.web> section:

    <machineKey validationKey=”AutoGenerate,IsolateApps” decryptionKey=”AutoGenerate,IsolateApps” validation=”3DES” decryption=”3DES”/> 

  4. **NOTE**If you just insert this key in the web.config it will not work. You must search for “machinekey” and paste over the original text to ensure it works.

  5. **NOTE** If you copy this script directly into your web.config you will need to remove the double quotes and replace them or they will be in the wrong format for SharePoint to respond.

  6. Save the Web.config file.

  7. Restart the Microsoft Internet Information Services (IIS) service. To do this, run the following command at a command prompt: iisreset

Important Theoretically, the 3DES algorithm is less secure than the AES (Rijndael) algorithm. We recommend that you use the AES algorithm whenever possible to help secure your system. Important These steps may increase your security risk. These steps may also make the computer or the network more vulnerable to attack by malicious users or by malicious software such as viruses. We recommend the process that this article describes to enable programs to operate as they are designed to or to implement specific program capabilities. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this process in your particular environment. If you decide to implement this process, take any appropriate additional steps to help protect the system. We recommend that you use this process only if you really require this process.

**Note**  Once again, always always make a backup copy of your web.config before editing it. You may also have this same problem after you create your Shared Services Provider etc. You will have to make the same changes to the web.config for each separate IIS instance.

 
1 Comment

Posted by on June 3, 2009 in SharePoint Common Issues