Monday, March 10, 2008

Moss and Virtual IP's

If I remember correctly, there was an issue with SPS 2003 and using Virtual IP's in IIS. This is still the case.

I've run into this a few times in different ways, if you assign an IP to an IIS virual server, some of SharePoint's features won't quite work correctly.
Virtual IP's are extra IP's you have added to your computer, and then set each IIS virtual server to only watch for traffic on the specified IP. These are sometimes used for load balancing, or if you don't trust host headers to forward traffic to the correct web application in IIS.

1: Using a dedicated search index machine. When you use central admin to pick a machine that should be dedicated for search, it will change your hosts file to point all requests for to the IP assigned to that machine. You won't be able to change this, since SharePoint will wipe out any changes that you make. This fine, unless you assign a virtual IP in IIS to the web application that is running your site. SharePoint will set the hosts file to use the physical IP of the machine, not the virtual IP. This will break search since IIS will not pick up the request since it is setup to only watch for traffic on a different IP.
The solution is to edit the hosts file yourself, and tell SharePoint to use all servers for indexing. It is convenient to use the central Admin UI to setup which machine will be used to search, but it does nothing more than change the hosts file. You can do this manually and have more control.

The hosts file allows you to override what DNS says. If your DNS server is setup to point to, you can add a line in your hosts file to look somewhere else. This is especially useful for testing. The hosts file is located at:
C:\windows\system32\drivers\etc\hosts. It does not have an extension and can be edited using notepad.

2: Alternate access mappings. If you are using Virtual IP's for your IIS virtual servers, setting up an alternate access mapping in CA is not enough to get it to work. You will also have to go into IIS and manually add the host header to the virtual server.

Thursday, March 6, 2008

Infopath and Site columns

When publishing a form in infopath, you are given the ability to match fields in your form to site columns.
Be careful not to create two site columns with the same name in the same category. Infopath has a bug in that it will let you see that you have two columns with the same name, but will only let you pick the first one. It seems that it matches by name, and not by the internal name. You can pick the second field, but if you go back to edit it again, you'll see that it goes back to the first field.

This is only an issue when publishing to a sharepoint site.

Admin Deployed Forms VS. Content Type Deployed Forms

There are a few Gotcha's around form deployment. Here are some Pro's and Con's of each:

Document Library:
Limited to one document library.

Content Type:
Limited to one site.
Infopath May timeout on upgrades if you have too many fields. I ran into this error around 25 fields. During the publishing process you will receive an error "Updating site content type failed." This is due to the fact that Infopath has a 30 second time out. If it does not finish it just gives up. I worked through this with premier support. It was suggested I use admin deployed forms.

Admin deployed forms:
More complex publishing process. Has effects on content deployment due to it being a feature.
Does not update content types. If you change the number of published fields, you will have to wipe out the content type and re-deploy. This is not possible after it has gone live since you will have to delete all the forms that have been created.

Turn Off Hover Over Screen Tips on Browser form

The easiest way to make a field required on an infopath form is to check the 'cannot be blank' box. The user must fill in data on the field to be able to submit the form. This also adds a red star to the field so the user knows they must enter data.

The problem is that it also adds a hover box which says 'Required' or something like that. This box is annoying to users because it often hovers over another field, blocking the user from entering data into the other field.

Here's how to get rid of it:

Edit the Core.JS file(12\template\layouts\inc)
Find the function called ErrorVisualization_ShowShortMessage, around line 5125.

You want to change this function to do nothing. the easiest way is to add: return; as the first line of code that it runs.
It should look something like:

function ErrorVisualization_ShowShortMessage(objControl,boolIsSticky){;

The hover boxes won't appear anymore.

You could get a little fancier and have it check the error string. Then, in infopath, set the ones you don't want to show to be 'xxxx' or something. Have the function check the string. If is your 'xxxx' string, then return, else show the message.
For example, I added:
if(strErrorString=="Required" strErrorString=="Cannot be blank" strErrorString =="Only date allowed (example: 2001-03-14)") return;
var strErrorString = objDatum.GetErrorMessage();

Now, my custom messages appear, but the default ones do not.