Monday, 26 November 2007

SharePoint development, here I come!

I am entering a new phase of my career today, attending the first of a 5-day course titled "Introduction to C# Programming with Microsoft .NET". I'm hoping that I can take what I learn here, and along with previous experiences of programming back in the day, start to expand my capabilities to include some development in SharePoint.

Whilst I will never be a full-scale application developer, I'm hoping that it will make me a more rounded SharePoint consultant with the capability to add extra value to the SharePoint deployments that I am involved in.

I also intend to publish the majority of Web Parts and tools that I develop through this blog, so watch this space (hopefully!)...

Wednesday, 10 October 2007

Search problems with large SharePoint groups

Had a problem where the search facility was indexing some site collections but not others - even though they were in the same namespace (i.e., couldn't have been proxy exceptions, etc.).

The crawl log listed errors against the site collection URLs saying "Element Not Found". The gather logs also reported the following for each site collection URL:

10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable STS3::COWSSecurityObject::AddUserToACLs: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:1637
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable STS3::COWSSecurityObject::Init: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:1396
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable STS3::COWSSite::AddScope: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:1171
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable STS3::COWSSubWeb::InitSecurity: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:2332
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable STS3::COWSSubWeb::Initialize: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:2163
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable CSTS3Accessor::InitURLType: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3acc.cxx Line:1500
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable CSTS3Accessor::InitURLType fails, Url sts3s://portal.edulink.internal/siteurl=/siteid={6b5da8a8-fdb4-419f-a82d-aaef67d6c7a9}/weburl=/webid={e480f6f1-472e-4770-9b70-2115c1089400}, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3acc.cxx Line:172
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable CSTS3Accessor::Init fails, Url sts3s://portal.edulink.internal/siteurl=/siteid={6b5da8a8-fdb4-419f-a82d-aaef67d6c7a9}/weburl=/webid={e480f6f1-472e-4770-9b70-2115c1089400}, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3handler.cxx Line:238
10/09/2007 13:20:14.37 mssdmn.exe (0x0424) 0x0E04 Search Server Common PHSts 0 Monitorable CSTS3Handler::CreateAccessorExB: Return error to caller, hr=80070057 - File:d:\office\source\search\search\gather\protocols\sts3\sts3handler.cxx Line:256

The problem was a SharePoint group present in the top level site of each site collection with membership of just over 1900 accounts. I removed the group in each top level site and this resolved the issue.

The "Plan for software boundaries" guide at http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true suggests a limit of 2,000 security principals per Web site, so it could be this. However, the users still existed in the site collection after I removed the group, so it was probably related to the number of users in the SharePoint group instead.

Friday, 28 September 2007

Using stsadm to add users to a SharePoint group

At first glance, the stsadm adduser command seems a bit of a pain when adding users into SharePoint because you have to specify a userlogin, useremail and username variable when using the command - these are not optional.

However, I have found that when I use dummy names for the useremail and username variables, the user profile database in MOSS overwrites them once the user has been added to the group. So, I used the following stsadm command to add users to a SharePoint group, which can be useful when you have bulk users to add from a CSV file:

stsadm -o adduser -url http:// -userlogin -useremail test@test.com -group "" -username "Test User"

For example,

stsadm -o adduser -url https://portal.edulink.internal -userlogin EDULINK\phil.childs -useremail test@test.com -group "Corporate Users" -username "Test User"

Once added, wait a few seconds and the e-mail address and user name changes from test@test.com and Test User to the correct one specified in the user profile database. Make sure that you test this with one user first though, before creating a script to add 1000 users all at once!

Thursday, 27 September 2007

Catalog 'index file on the search server Search' error on WSS 3 Search service

Everything was running fine for a couple of months and then the following error started to appear on the index server every five minutes:

Event Type: Error
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2424
Date: 27/09/2007
Time: 13:40:01
User: N/A
Computer: EP-SP-INDEX01
Description:
The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again.

Context: Application 'Search', Catalog 'index file on the search server Search'

There are lots of articles on this, one of them with a list of 15 suggestions to resolve the problem! However, I managed to find an article from Ivan Wilson at http://guru-web.blogspot.com/2007/08/wss-30-content-indexing-update-cannot.html that solved it for me (thanks, Ian). Ian says as follows:

"I fixed this by going to Central Administration – Operations – Services on Server. I selected the Windows SharePoint Services Search entry. I then changed the Service Account username and password to match the Content Access Account details. Click OK on the bottom of the page and wait five minutes."

"Once I saw that the error was no longer being logged I went back and set the Service Account back to its original username and password. Still no sign of the error. I also verified that WSS was indexing content again."

So that is exactly what I did. I had two service accounts - one called SP_WSS_SearchSVC and SP_WSS_SearchCA, so I entered the SVC account for both the service account AND content access account, restarted the service and it worked.

The only thing that differed from Ian's findings were that when I returned it back to having the SVC account as the service account and CA account as the content access account, the error reappeared straight away, except that it also reported a one-off error with trying to read the Central Administration site, as follows:

Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
Date: 27/09/2007
Time: 13:50:01
User: N/A
Computer: EP-SP-INDEX01
Description:
The start address cannot be crawled.

Context: Application 'Search index file on the search server', Catalog 'Search'

Details:
(0x80131534)

Not sure why all this started (it may have been after some SQL maintenance plans were run), so it's probably something to do with permissions somewhere, but rather than spend an age trying to discover what it was, I ended up using the service account for both services and content access - There shouldn't be any security implications of doing this because both accounts are only Domain Users, with identical SQL permissions, and this is only for indexing the WSS help files anyway. The only difference is that the service account is being used to run the Windows service, which gives it slightly more permissions on the Index server itself.

Wednesday, 26 September 2007

Getting the Document Conversions Service running on a server farm

I have two front-end Web servers and an Index server and I want to install the Document Conversions Load Balancer and Launcher service on the Index server. I chose this configuration rather than load balancing the Launcher service across the front-ends based on the recommendations in this article: http://technet2.microsoft.com/Office/en-us/library/f7d7b652-10cc-4c99-8c05-0cc4341d4d941033.mspx, and also because resilience of the Document Conversions service was not required.

I also followed the instructions titled "Configuring document conversions in a server farm" at the bottom of this article because the registry entries did need be set manually. After doing this, the Load Balancer service started fine but the Launcher service just hang on "Starting".

I then found another article (not referenced at all in the first article) called "The Document Conversions Launcher Service status on a SharePoint Server 2007 Web front-end server displays "Starting" but does not start or stop" at http://support.microsoft.com/kb/941212. I went through the instructions on this article and the Launcher service started successfully.

This article mentions the problem if you are trying to start the Launcher service on a second Web Front-End server - but in my example, I was trying to start it on the Index server.

Monday, 10 September 2007

Nothing appears in the site collection usage reports pages

Had the problem where the MOSS usage analysis processing logs were being created correctly in the default LOGS folder, but nothing appreared in the site collection usage reports pages.

Strangely, I could also successfully create reports in SharePoint designer and view the usage reports for each individual site at /_layouts/UsageDetails.aspx.

Well, surprise surprise it was a permissions issue. To get it working I added the local WSS_WPG account to the LOGS folder and gave it Read/Write/Modify permissions. However, even though there are log files dating back 1 month, the usage reports page only shows data from when I added the WSS_WPG account to the logs folder, so you will need to wait 24 hours before the first data appears.

Wednesday, 29 August 2007

Choosing members of an existing group for user profile import

I needed to set up a User Profile import connection to include members of a specific group rather than the whole directory (can be quite useful for preventing lots of useless account appearing, such as service accounts). This is what I did:

- Go to Site Settings > Manage profile database > Configure profile import.

- Select “Custom Source“. This will let you create import connections

By the way, this is also how you can configure to import from multiple domains in a forest without having to specify the entire forest

Also, this is how you get the “Manage connections“ link on the Manage Profile Database screen

- It should ask you for the connection settings

- Fill in User Filter

Format:
(&(objectCategory=Person)(objectClass=User)(memberOf=[distinguised name of the group]))

Example 1 - This LDAP query selects any account from members of the specified group in AD:
(&(objectCategory=Person)(objectClass=User)(memberOf=CN=Group1,OU=Domain Distribution Groups,DC=domain,DC=co,DC=uk))

Example 2 - This LDAP query selects only enabled accounts from members of two groups in AD:
(&(objectCategory=Person)(objectClass=User)(!userAccountControl:1.2.840.113556.1.4.803:=2)((memberOf=CN=Group1,OU=Domain Distribution Groups,DC=domain,DC=co,DC=uk)(memberOf=CN=Group2,OU=Domain Distribution Groups,DC=domain,DC=co,DC=uk)))

Wednesday, 22 August 2007

Problems getting the MOSS RSS Viewer working through a proxy server

This is quite a common problem, but I am posting it here in case I forget it later!

It is well documented that you have to add an entry into the web.config file in C:\Inetpub\wwwroot\wss\VirtualDirectories\, but I found that it can be quite fussy as to how these lines are formatted. The lines I added were as follows (I have left the /appSettings and /configuration references in as pointers):

</appSettings>
<system.net>
<defaultProxy>
<proxy usesystemdefault = "false" proxyaddress="http://proxy.domain.internal:8080" bypassonlocal="true" />
</defaultProxy>
</system.net>
</configuration>


These are the things that I tried to get it working:
- Ensured that all the indentations were correct for the system.net and defaultProxy references.
- Entered http:// at the start of the proxy address rather than just have the FQDN.
- Ensured that there were no blank lines between any of the code.

Wednesday, 1 August 2007

ISA Server 2006 and Windows Server 2003 SP2

I would strongly advise following steps 2 and 3 in the following article BEFORE installing ISA Server 2006 on 32-bit Windows Server 2003 with SP2: http://blogs.technet.com/isablog/archive/2007/03/27/isa-server-and-windows-server-2003-service-pack-2.aspx. BTW, step 2 only needs to be done on multi-core multi-processor servers (mine were 2 socket dual core HP DL380's).

I had all sorts of issues before implementing these fixes - I couldn't tell you wish one solved the problems but it is probably a good idea to do both just in case.

If implementing step 2 and setting the mask to assign NICs to separate processors, I assigned NIC1 port A to processor thread 0, NIC1 port B to processor thread 1, NIC2 port A to processor thread 2 and NIC2 port B to processor thread 3.

Thursday, 26 July 2007

Customisations to the Content Query Web Part do not appear for 'normal' users

I customised the Content Query Web Part to show additional columns from Announcements lists, but these columns could only be viewed in the Web Part by Site Collection Administrators - 'conventional' users (even administrators of the root site) could only see the default title column of each announcement.

To resolve this, the ItemStyle.xsl and ContentQueryMain.xsl files that I customised needed to be checked in as major versions. I had initially tried to do this with SharePoint Designer, which appeared to show them as checked in, but it was only when I looked at the Style Library using a browser that I could see what the problem was - a mandatory column called "Title" needed to be completed before they could be checked in.

I edited the properties of each file, gave them a title, and then checked them in as major versions.

Wednesday, 25 July 2007

6482, 7076, 6398, and HRESULT 0x80005006 errors on second front-end server

Intermittently getting the above errors on my second MOSS front-end server after running an MS hotfix. This server is also hosting a second instance of the Central Administration Web application for resilience purposes.

A lot of advice recommends running a .NET 2.0 hotfix to resolve, but as this was only happening on my second front-end server I wasn't convinced that this would solve the issue (also, others on the Web also found that it went away for a few days but came back again).

Followed some advice after extensive searching on the Web to remove the Central Administration Web application using the SharePoint Configuration Wizard and reinstall it back again afterwards. I have done this and so far everything works fine, although the error still may appear again in the future.

Profile import works but get Error 7888 in the event log

Everytime a profile import is run (full or incremental), everything seems to go through successfully, but there is the following error in the event logs:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 24/07/2007
Time: 22:00:34
User: N/A
Computer: EP-SP-INDEX01
Description:
A runtime exception was detected. Details follow. Message: Access Denied! Only site admin can access Data Source object from user profile DB.

Techinal Details: System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB. at Microsoft.Office.Server.UserProfiles.SRPSite.AdminCheck(String message) at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(IDataRecord rec) at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(String strDSName) at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead) at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site) at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.GetDataSource() at Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)

I resolved this by doing the following:
- Go into the Shared Services administration page.
- Click 'Personalization Services Permissions'.
- Add the search service account (in my case this was DOMAIN\sp_search_svc) and give the account 'Manage User Profiles' permissions.

Errors 5555 and 7888 in the event log

We wanted to change the content database location from the SQL netbios name to the SQL FQDN instead (apparently this improves performance of db access) - so we removed reference to the content databases in Central Administration and re-attached them. What we should have done first is used the stsadm preparetomove command before doing so, creating the following messages in the event viewer:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: User Profiles
Event ID: 5555
Date: 24/07/2007
Time: 16:00:01
User: N/A Computer: EP-SP-FE01
Description:
Failure trying to synch web application 43caed9b-30c4-4b56-a5dd-3973ef92e354, ContentDB a5c17eb0-94bf-4362-87b1-be274bb5cc03 Exception message was A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 24/07/2007
Time: 16:00:01
User: N/A
Computer: EP-SP-FE01
Description:
A runtime exception was detected. Details follow. Message: A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

Techinal Details: Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue. at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy) at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds() at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

To resolve the situation we ran the following command on one of the front-end servers:
stsadm -o sync -deleteolddatabases 0

This sorted the problem, but it would have probably been better to use the preparetomove command in the first place. As to whether using the SQL FQDN improved performance or not - it didn't seem to make any difference whatsoever!

Tuesday, 24 July 2007

"Failed to configure propagation share" error when configuring search server

I have two front-end servers and a dedicated index server - FE01, FE02 and INDEX01. I configured the index server as an indexer and FE01 as a search/query server with no problems. However, when I tried to configure FE02 as a second search/query server, I got the error message "Failed to configure propagation share".

I couldn't find any resolution on the Web, so this is how I sorted it:

1. Manually configured the Office SharePoint Server Search service as Manual startup and the Search service account credentials (domain\sp_search_svc) on the Log On tab. I did NOT start the service.

2. Navigated to the SharePoint data folder 'E:\Program Files\Microsoft Office Servers\12.0\Data\Office Server' and created a new folder called 'Applications'.

3. Shared the folder with the share name 'searchindexpropagation' and description 'Microsoft Office SharePoint Server Search propagates index files through this share'.

4. Configured Full Control share permissions for the 'sp_search_svc' domain account & 'wss_admin_wpg' local group.

5. Configured folder security by adding Modify permissions to the 'sp_search_svc' domain account.

6. Configured the search/query server as normal through Central Administration, but instead of selecting to auto-create the propagation share, I selected to use STSADM instead.

Tuesday, 10 July 2007

Persistent cookies and Office applications

By default in Vista IE7, persistent cookies are not shared with Office applications due to the “Protected Mode” setting in IE. For a work around, please refer to 932118 Persistent cookies are not shared between Internet Explorer 7 and Office applications in Windows Vista http://support.microsoft.com/default.aspx?scid=kb;EN-US;932118