Home - From The Field

5/30/2008

Authenticated Bind to LDAP with MOSS Profile Import

My customer used Novell eDirectory and had linked MOSS to it via a membership provider entry in the web.config of their intranet web app. They were using forms based authentication to login to MOSS with their Novell accoutns and it was working a treat.

They also wanted to run a profile import from Novell to MOSS. The profile import was sorta-working but the customer wasn't happy with the format of the full name of the user.

The problem was the profile import was filling in the Preferred name field with the membership provider name : account name.

The customer wanted the preferred name to be in a First Name + Surname format.

I wrongly assumed the import was using values, like username and password, from the Membership Provider section of the web.config to run.

We ran various tests, changing different values in the web.config. We eventually established that the profile import doesn’t use the web.config at all - it only refers to the MOSS profile import connection page.

The import was filling in the Preferred name field with the membership provider name : account name because it was doing a anonymous bind with Novell LDAP. Because it was anonymous the import didn’t have access to the displayName field in LDAP which was mapped to Preferred Name in SharePoint.

We established that Novell only allows access to certain inetorgperson attributes using an anonymous bind. The preferred name attribute that the customer wanted is one of those that needs authentication.

To do an authenticated bind with LDAP you need MOSS Sp1 and the credentials in the profile import connection page. Once we put the distinguished name of a user with rights in LDAP it worked.

Posted at 8:03 AM by EUROPE\mmunslow | Category: Authentication | Permalink | Email this Post | Comments (0)

5/26/2008

“Anonymous Authentication” and “Deny All” policies in SharePoint

We always get the most interesting cases and questions J

Last week, there was another interesting question. A customer was questioning why a deny policy would invalidate anonymous access to a web application.

Before any comments, I wanted to validate the situation. So I opened a virtual lab on TechNet.

1. I changed the IE settings to avoid sending credentials to Trusted Sites.

2. Then I browsed http://www.litwareinc.com . Here is the resultant HTTP 401.2 (Unauthorized: Access is denied due to server configuration (IIS)) page: Unauthorized 401.2

3. Then I enabled Anonymous settings on the web application like this: Central Administration Anonymous access

4. And finally, I enabled anonymous access to the root site collection like below. Of course, I got prompted for credentials to get there… Site Settings Anonymous Access

5. Because this is a publishing site, I am done at this point. Used my desktop shortcut and I am on the site anonymously… Anonymous web site

Now, time to test the situation in question:

6. I browsed to the central admin, and added a deny policy for Brian Cox:

7. Then I tried to use my shortcut again and (voila) I get a login prompt:

8. If I cancel the authentication prompt, it is followed by a 401 unauthorized access page: Unauthorized due to deny policy

Note that this page is different than what I initially saw before I enabled anonymous access. This is not directly coming from IIS anymore!

9. If I accept and provide Brian Cox’s credentials, I get the usual SharePoint access denial page: Access Denied for Brian due to policy

So, the deny policy not only blocked Brian, but also effectively blocked anonymous access to the site.

Even this sounds shaky, this is an expected behavior. Since the deny policy is enforced on a web application level, SharePoint will try to authenticate you even before checking the ACL’s of the requested site collection.

So by doing a configuration like this, you are telling sharepoint “Everybody in the world can browse this site, but Brian Cox cannot even get to this web application.” Poor SharePoint has no choice but authenticate everybody to make sure that they are NOT Brian Cox. J You have successfully invalidated anonymous access!

Remember that, similar to this particular scenario, in many web single sign on applications; because the request has to be authenticated BEFORE it gets to the target site, you will not be able to use anonymous access.

HTH

Duray AKAR

Posted at 11:36 AM by NORTHAMERICA\duraya | Category: Authentication | Permalink | Email this Post | Comments (0)

3/17/2008

STSADM Catastrophic Backups Failing

I recently came across an issue with a customer with their nightly stsadm farm (Catastrophic) backups which were failing.

They were using the following stsadm command to create the backups -

stsadm -o backup

-directory <UNC path or local drive>

-backupmethod <full or differential>

[-item] <created path from tree>

[-percentage] <integer between 1 and 100>

[-backupthreads] <integer between 1 and 10>

[-showtree]

[-quiet]

I took a look at the backup log file that is generated during the backup (spbackup.log) and found that the backups were backing up all components successfully but were pausing at the Index backup step for 3600 seconds (1 Hour).

I took a look in the Application Event Log and found the following entry, this occurred prior to the backups initially starting to fail.

A master merge cannot be started for catalog AnchorProject due to error The file exists. 0x80070050

To resolve the issue I launched the SSP Administration site (the customer had a single SSP) selected Search Settings, I then went into Search Settings.

Within Search Settings there is an option to Reset All Crawled Content, I selected this, and once the Index had been reset I performed a manual Full Crawl.

WARNING: Resetting the Index will delete the Index and end users will not be able to search content until a Full crawl has been performed, depending on the amount of data to be indexed this could take a significant amount of time.

I them ran a stsadm catastrophic backup which successfully backed up all components – including the Index J

Posted at 5:20 AM by EUROPE\brendg | Category: Troubleshooting | Permalink | Email this Post | Comments (0)

3/7/2008

Using Windows Server 2008 as the client for a MOSS demo

In a recent conversation with Mark Harrison he asked the question as to whether I knew how to enable WebDav for the client when the client was a Windows 2008 Server.

I can't claim to have found the answer but Mark came back to me with the solution after he found it so I'm posting it here for you too.

Mark has blogged it here and the solution is to install the desktop experience feature as follows.

To install Desktop Experience
Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.
Under Features Summary, click Add features.
On the Select Features page, select the Desktop Experience check box, and then click Next.
On the Confirm Installation Selections page, verify that the Desktop Experience feature will be installed, and then click Install.
On the Installation Results page, you are prompted to restart the server to finish the installation process. Click Close, and then click Yes to restart the server.

After the server restarts, confirm that Desktop Experience is installed.
Start Server Manager.
Under Features Summary, confirm that Desktop Experience is listed as installed.

Posted at 2:51 PM by EUROPE\neilh | Category: Troubleshooting | Permalink | Email this Post | Comments (0)

2/21/2008

Installing SP1 for MOSS with additional Language Packs

Yesterday a colleague forwarded a question to me.

"We have installed MOSS 2007 and the MOSS Language Pack for French on the Servers. Two Front End Web Servers and a Indexing/Application Server. Which WSS and MOSS Service Packs do we need to install and in what order do the service packs need applying to the system."

So to answer the question:

I am assuming MOSS2007 base install is English/US and just the single MOSS language pack for French has been added.

Useful resources and pieces you will need

Base WSS SP1 - 32bit and 64bit - http://www.microsoft.com/downloads/details.aspx?FamilyId=4191A531-A2E9-45E4-B71E-5B0B17108BD2&displaylang=en

Base Moss SP1 - 32bit and 64bit - http://www.microsoft.com/downloads/details.aspx?FamilyID=ad59175c-ad6a-4027-8c2f-db25322f791b&DisplayLang=en

How to Install WSS Software Updates - http://technet2.microsoft.com/windowsserver/WSS/en/library/91649a7e-6b5a-4e5a-9ee5-51951f4b857f1033.mspx?mfr=true

How to Install WSS Software Updates - http://technet2.microsoft.com/Office/en-us/library/f484f5f2-35bb-4d70-bf56-dd1c4c287c721033.mspx?mfr=true

How to Deploy ALL MOSS Server Updates General Information - http://support.microsoft.com/kb/945013

Language Pack Download for WSS SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyID=05046b1d-dd7b-456a-8838-8d978c5f3579&DisplayLang=en

Language Pack Download for MOSS SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyID=3a6c26fd-0beb-40d5-8cba-15164faab150&DisplayLang=en

Sequence

There is a generic sequence you can folllow for each of the updates. You have 4 service packs in total that need to be deployed to a total of 6 servers.

The running order is server hosting the central admin site followed by all the others.

The SP installation order is WSS SP1 > WSS Language Pack SP1 > MOSS SP1 > MOSS Language Pack SP1.

Although the suggestion below indicates you need to run the PSCONFIG utility after each service pack install strictly speaking that isnt true. In the case of a WSS SP1 and MOSS SP1 install you can install the WSS SP1 binaries immediately followed by the MOSS SP1 binaries. After both of these have been completed PSCONFIG can be used to upgrade the farm for both service packs. The reason I suggest running PSConfig for each SP is that in the event of an upgrade failure it will make troubleshooting that much easier.

For each Service Pack do the following

1. Disconnect users from the server farm by stopping the World Wide Web Publishing service (w3svc) on all Web servers.

2. Begin the software installation on the server hosting the central admin web site

3. At the end of the software update installation, the SharePoint Products and Technologies Configuration Wizard start

Note: If the wizard does not start automatically, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

4. On the SharePoint Products and Technologies Configuration Wizard Welcome page, click Next.

5. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

6. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

7. When the dialog box about installation in a server farm appears, do not click OK. Instead, leave each server with the following dialog box displayed: - THIS IS CRITICAL TO THE SUCCESSFUL INSTALL

You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

8. When the dialog box from the previous step is displayed on all Web servers in the server farm, use one Web server that hosts the Central Administration Web site to finalize the installation.

9. On the server you selected in the previous step (Step 2), click OK.

10. On the Configuration Successful page, click Finish.

11. Continue updating the remaining computers in the server farm, one at a time, by clicking OK in the dialog box.

Note: It is important that the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.

Again, once the first farm member has completed the upgrade you can complete the upgrade on all the other machines in parallel since all the database upgrade steps have already been completed.

When the software update installation and configuration is complete on all the Web servers in the server farm, make the Web servers available to users by manually starting the World Wide Web Publishing service on each server on which you manually stopped the service.

OK after this you can move onto the next service pack in the list.

You can verify successful install of the servicepack by following this process after Step 10 above.

Verify installation
After you install a software update, you should verify that the installation was successful by reviewing the upgrade log file (Upgrade.log), as described in the following procedure.

To view the upgrade log file

1. Use Windows Explorer to navigate to the %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS folder.

2. Use a text editor to open the Upgrade.log file.

3. Scroll to the date on which you installed the software update.

4. Search, or visually scan, for the following entries:

Finished upgrading SPFarm Name=<Name of Configuration Database>

In-place upgrade session finishes. Root object = SPFarm=<Name of Configuration Database>, recursive = True. 0 errors and 0 warnings encountered.

If you find these entries, the installation was successful.

5. If you do not find the entries from the previous step, you can identify specific issues that may have contributed to the failure by searching, or visually scanning, through the Upgrade.log file for the following terms:

• fail

• error

After you identify and resolve the blocking issues, you must force a software update

To force a software update

1. Force a software update operation by opening a Command Prompt window and changing to the following directory:

%COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin\

2. Type the following command:

psconfig –cmd upgrade –inplace b2b –wait –force

Happy Upgrading

Posted at 4:00 PM by EUROPE\neilh | Category: Upgrade | Permalink | Email this Post | Comments (3)

1/29/2008

Faceted Search

Premier Field Engineering legend Neil Hodgkinson (the SharePoint team lead engineer in the UK) has just posted on the SharePoint Product Group blog no less!

Read Lawrence Liu's intro to his post:

"This first of two guest blog entries, written by Neil Hodgkinson, a Microsoft Premier Field Engineer based in the UK, will cover the "why we did it" aspect of the open source faceted search solution for MOSS 2007 and MSS 2008 that has been released on CodePlex at http://www.codeplex.com/facetedsearch. The second guest blog entry, scheduled to be posted within a couple of weeks, will be written by Leonid Lyublinski, a Microsoft Consultant based in Ohio, USA, and will cover the "how we did it" aspect of the solution."

Read Neil's post:

http://blogs.msdn.com/sharepoint/archive/2008/01/30/open-source-faceted-search-for-moss-2007-and-microsoft-search-server-2008-part-1-of-2.aspx

Nice one Hodge!

Posted at 8:46 PM by EUROPE\mmunslow | Category: Search | Permalink | Email this Post | Comments (1)

1/11/2008

Event ID's 7076, 6398 and 6432 - Now Fixed

A few months back Matt Munslow posted an article 'Timer Job Shocker'. This post mentioned how IIS Manager failed to open and Event ID's 7076, 6398 and 6432 were appearing in the event logs repeatedly with a message: "Attempted to read or write to protected memory".

Microsoft has now found the root cause of this problem to be the IIS ADSI provider. Essentially, if you have a process with more than one thread and two threads access IIS 6.0 at the same time, then this issue occurs.

This problem is likely to occur for the SharePoint Timer service (OWSTimer.exe) in Microsoft Office SharePoint Server 2007. When this occurs, you may find that:

In SharePoint Server 2007, tasks that are scheduled do not run.
When you try to manage IIS 6.0 by using Server Manager, you receive a blank page, or you receive the following error message: "the path specified cannot be used at this time".

The Event ID's 7076, 6398 and 6432 and memory error messages described above will also be recorded in the Application Event Logs.

Microsoft now has a KB article describing this problem http://support.microsoft.com/?id=946517 along with details of the fix and how to obtain it.

This fix is an IIS fix so you should be able to install the fix regardless of what SharePoint Service Pack level you are running.

Posted at 3:24 AM by EUROPE\chwhite | Category: Troubleshooting | Permalink | Email this Post | Comments (1)

12/17/2007

Using a dedicated Web Front End for crawling

One thing to watch out for when using Search with a dedicated web front end for crawling and running MOSS 2007 in least priveleged mode as per the following documents.

Plan for administrative and service accounts (Windows SharePoint Services)
URL: http://technet2.microsoft.com/WindowsServer/WSS/en/library/89e4c579-5720-45e0-917e-abeb95266c3e1033.mspx

Configure a dedicated front-end Web server for crawling (Office SharePoint Server 2007 for Search)
URL: http://technet2.microsoft.com/Office/en-us/library/1ac6211c-8708-4fbd-a1b8-12e30a8a7ffd1033.mspx

The Server Farm Account requires Modify permission to the hosts file on the server (c:\windows\system32\drivers\etc) otherwise it cannot create an entry within the hosts file on the server that holds the Index role.

An entry in the hosts file is required to ensure that the Index server connects to the dedicated web front end and doesn't connect to any other WFE's within the farm.

Posted at 5:23 AM by EUROPE\brendg | Category: Search | Permalink | Email this Post | Comments (0)

12/16/2007

Office SharePoint Server 2007 Training Portal

The Microsoft Office SharePoint Server 2007 Training Portal Edition, built on the Microsoft SharePoint Learning Kit, is designed for server administrators who want to help their end-users learn how to use the features of Microsoft Office SharePoint Server 2007. The Training topics lead the learner step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.

Check it out:

http://www.microsoft.com/downloads/details.aspx?FamilyID=673dc932-626a-4e59-9dca-16d685600a51&DisplayLang=en

Posted at 8:07 PM by EUROPE\mmunslow | Category: Training | Permalink | Email this Post | Comments (0)

Service Pack 1 Is Out There!

Windows SharePoint Services 3.0 with Service Pack 1

http://www.microsoft.com/downloads/info.aspx?na=22&p=1&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3def93e453-75f1-45df-8c6f-4565e8549c2a%26DisplayLang%3den

Windows SharePoint Services 3.0 x64 with Service Pack 1

http://www.microsoft.com/downloads/info.aspx?na=22&p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d9fb41e51-cb03-4b47-b89a-396786492cba%26DisplayLang%3den

Windows SharePoint Services 3.0 Service Pack 1 (SP1)

http://www.microsoft.com/downloads/info.aspx?na=22&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d4191a531-a2e9-45e4-b71e-5b0b17108bd2%26DisplayLang%3den

Windows SharePoint Services 3.0 Language Pack Service Pack 1 (SP1)

http://www.microsoft.com/downloads/info.aspx?na=22&p=4&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d05046b1d-dd7b-456a-8838-8d978c5f3579%26DisplayLang%3den