Pages

Tuesday, 1 April 2008

Hiding Users From The CRM (3.0 / 4.0) Service Calendar

I was fiddling with the CRM Filtered Views today for a report I'm writing for a customer. One of the views I was dealing with was the FilteredSystemUser view. This view is the one which displays attributes for the User entity in CRM.

I suddenly came across an interesting attribute I had not noticed before named displayinserviceviews. This caught my attention as it had the potential of solving a problem which has plagued me for a long time - How do I hide certain users from the Service Calendar so they are not displayed as resources?



Turns out there was a really simple solution for this. I was very pleased! :)

All you need to do is add this attribute to the User form in the CRM customization section and then you'll have a new bit (yes/no) field in the User form which will allow you to choose whether or not the user will be available as a resource in the Service Calendar.

Couldn't be simpler! :)

Monday, 31 March 2008

MOSS 2007 / WSS 3.0 Search Indexer Gets Stuck

Now I know this is not a new subject and the solutions are out there. So I'm writing this (short this time) article as a basic summary of what I've come across.

So what's the problem?
Some of you must have come across this before. The Shared Service Provider's crawler get stuck and you can't stop it. It also does not add any new items to the index.

I've found two great articles that deal with this issue.
The first one by Mike Hanley explains how to resolve this issue with clear instructions and good screenshots. It can be found here.
The second is a support KB by Microsoft which expands what is explained in Mike's article by adding more tables which need fixing. It can be found here under KB930887.

Sunday, 10 February 2008

Datetime field bugs

Update 24/04/08 (Solved!) - There is an official hotfix available which resolves this issue. You'll have to request it from Microsoft but it's available here: http://support.microsoft.com/kb/948157.

Update 15/02/08 - Partial solution provided by Microsoft Support. As this is not exactly a supported fix, please contact me privately for details or leave a comment and I'll contact you.

CRM 4.0 coming out just at the turn of a year and customers going from 2007 to 2008 in various date fields raised an interesting bug.

The problem is with saving forms where I try to enter a date at the beginning of any year like 01/01/2008 I get the following error:

This error basically states "Invalid Argument" for the newly entered date value. Which is odd, as this is a real date.

Turning on the DevError flag produces the following output when I attempted to open anything saved with a "bad" datetime value. This was followed by a long stack trace.


System.ArgumentOutOfRangeException: Specified argument was out of the range of
valid values.Parameter name: GetDaylightChanges actual year: 2007,
MinValue.Year: 2008, MaxValue.Year: 9999
After studying this problem further, I came across an interesting behavior. I changed the datetime field so it would not just show the date but also the time values. I then started playing with the time values and attempting to save each time. This problem only arrose between 12:00am and 02:00am (02:00am was the first time value that allowed me to save). This seemed odd but then I remembered my user was configured to work in the GMT+2 time zone. I Then attempted this with the GMT+5 time zone and it behaved in the exact same way apart for it starting to work properly at 05:00am.

This all struck me as being very odd. To try and narrow down the issue, I wanted to see if this only happens when moving between years or if it also arrises on the first day of any given month. I quickly attempted to enter a new date as the 01/02/2008 (first of feb) with different time values but they all worked. It appears the problems only happen when moving between years.

I'd just like to add that this happens with all date fields in the system. Default and custom entities with default or custom datetime fields. Any mix will do, all you need is a datetime field.

To sum up the results from my various checks, this problem only seems to happen when the value entered in any datetime field changes year values (ex. 2007 and 2008) when comparing the local time zone and the GMT time zone datetime values. This can be reproduced by entering a value on 01/01 of any year with a time value which is lower than your local GMT offset (ex. 01:30am for GMT+2 or 04:30am for GMT+5).
In addition, I have also performed the exact same tests on 3 different CRM 4.0 deployments in both clean installation and upgraded (from CRM 3.0) environments. They all performed in the exact same way.


Microsoft have provided me with an unsupported SQL script which temporarily fixes the issues described in this post. However, I would rather not make this fix publically available as it does involve directly editing the CRM databases.
A permenant hotfix will be made available for this matter shortly (I hope). I will post an update once this happens.