Problems with Peoplesearch in MOSS 2007

Today I ran into some problems concerning People-search in MOSS 2007. My customer was using https for their main sharepoint site and I had installed the mysite host on the same web application (in https://servername/mysite) according to the specifications found around the net.

Well, my customer just couldn’t get the people search to work, and I had heard that there were some problems with using it on a site that runs on https (http with ssl), so I wasn’t very surprised. As a bit of backgroud, the peoplesearch is set up as a contentsource in the search using sps3://servername. The server in this case should be the web application hosting mysite.

Well, how to solve it. First of all I tried to just create and extension of the sharepoint application on http port 2000 (http://servername:2000). It worked just as it should, when I browsed it, it worked and I was also tranfered to the default site (https://servername).

I tried adding this as a content source instead of the old one, in other words:
sps3://servername:2000, sadly it didn’t work.

As a matter of fact, we had got it to work previously in the same environment. We had first installed sharepoint on http://home and then added https://home.company.com with an extension and an alternate access mapping. The later was used as the address to be used from the outside, by using MS ISA as a reverse proxy. After a while, the customer complained about problems with people copying/emailing url:s that didn’t work from the outside. (the url was http://home/… and not https://home.company.com/…, so not very strange. This resulted in the action of removing the alternate access mapping of http://home (the original one) so that only https://home.company.com remained (and was hence set at the default). This worked great, people could enter “home” in their IE and they would reach the site https://home.company.com.

However, when I removed the alternate access mapping for http://home, people search started failing.

So, the remedy, I added an alternate access mapping for http://home:2000 in the zone Intranet (doesn’t really matter, which zone as long as it isn’t the default), re-indexed the search server and made a full crawl that worked like a charm! The point of using TCP port 2000 was that is is very unlikely that a user might just happen to enter that, it could just have been 1234 aswell…

Gustaf Westerlund
CRM and SharePoint Consultant

Humandata AB
www.humandata.se

First Titan/CRM 4 screenshots!

If you, like me, havn’t been able to test or have a look at the new Microsoft Dynamics CRM 4 (code named Titan), you can now. I havn’t seen any VPC out yet public but will let you know as soon as I know.

In the meantime, have a look at Stunnwares/Michael Höhnes site where he writes about the many new features of CRM 4. It’s been a long wait, but it has been worth it! CRM 4 seems to be great!

http://www.stunnware.com/crm2/topic.aspx?id=TitanBeta3

Gustaf

MS CRM 3 and Exchange 2007

As many of you probably have customers running Exchange 2007 or are considering running Exchange 2007, careful consideration has to be taken to the fact that the current CRM Email router does not support Exchange 2007 due to the fact that it is a 64 bit program, and the router is not. This is going to be fixed in CRM 4. For more information have a look at the CRM Team Blog: http://blogs.msdn.com/crm/archive/2007/09/27/crm-3-0-and-exchange-2007-compatibility.aspx

Gustaf

Interesting feature in SharePoint webpart properties

I am currently developing a customized search webpart for a customer and I wanted to move all environment specific variables to the webpart public properties so that they can easily be changed and the same dll can be used in all environments (dev and production). One of the properties was Scope, which defined search scope to use. It was defined in the following way:

private string scope;

[Browsable(true), Category(“Settings”),

DefaultValue(“Documents”),

WebPartStorage(Storage.Shared),

FriendlyName(“Scope”),

Description(“Define Scope of search”),

XmlElement(ElementName = “Scope”)]

public string Scope

{

get

{

return scope;

}

 

set

{

scope = value;

}

}

 

Well, just to be on the safe side, I set the web part property to “Documents”, which is also what I had used as default. I was very confused the next time I opened the “Modify Shared Webpart” menu and found that the field was blank! First I thought there was some error in how the property was defined, but after a while I found that it actually blank the field if it is set to the value defined as default (in this case “Documents”).

So, if you run into this little “feature”, don’t be afraid, everything is just as it should be!

Gustaf