I have been implementing a FIM2010 server as part of a solution that will ultimately upgrade ILM server to FIM. We are importing data from AD and exporting to a database. One of my users has an attribute containing a 450 character string. This works fine in ILM becausse the default type in mms_metaverse seems to be nvarchar(450) but when I attempt to synchronise in FIM it causes an unexpected-error. Investigation showed that to be a SQL stack overflow and looking at the mms-metaverse table for FIM all the defaults that were nvarchar(450) in ILM now appear to be nvarchar(448). Is this right or am I missing something? If this is the case, is this difference between ILM and FIM documented somewhere? I ran a pretty extensive search and could not find anything. Cheers, Eddie

There isn't much in the world about the database construction in ILM or FIM. I would imagine that this is by design -- Microsoft doesn't support any modifications to the database, and, I am sure doesn't document as a result. I am quite sure that change isn't documented, but it does seem to be the case... I am curious about what is represented with a 450 character string in your MV :)Aaron Sankey, Avanade

Eddie, FIM portal has an attribute type called 'indexed string' which is 448 chars. 'Unindexed string' has unlimited length. http://technet.microsoft.com/en-us/library/ff519007(WS.10).aspx So just change your custom attribute type to unindexed string.

There is a string that is a delimited list of services to which the user is subscribed. For most people it is under 450, but we have a couple of users for whom it is bang on 450.

Unfortunately that involves a full redesign of the metaverse schema and would have to be rolled out through Dev, Test, PreProd and Prod. We had designed around using the existing schema definitions from the ILM server and it was only when we rolled to Production that this issue was found. I was sort of interested to know why it was changed - and more importantly why the change is undocumented. Also - does anyone know what he implications are if we just redefine that field to be larger?

Unfortunately that involves a full redesign of the metaverse schema and would have to be rolled out through Dev, Test, PreProd and Prod. We had designed around using the existing schema definitions from the ILM server and it was only when we rolled to Production that this issue was found. I was sort of interested to know why it was changed - and more importantly why the change is undocumented. Also - does anyone know what he implications are if we just redefine that field to be larger?

I don't think you'll be able to increase default nvarchar(448) size in a legal way for metaverse. 'cause looking into [FIMSynchronizationService].[dbo].[mms_metaverse] it always nvarchar[448] either indexed or not. sure you can alter that SQL table, but who know what will happen then.... btw, a list of services as a string is a bad idea. why don't you use multivalue reference attribute type for it?

I don't think you'll be able to increase default nvarchar(448) size in a legal way for metaverse. 'cause looking into [FIMSynchronizationService].[dbo].[mms_metaverse] it always nvarchar[448] either indexed or not. sure you can alter that SQL table, but who know what will happen then.... btw, a list of services as a string is a bad idea. why don't you use multivalue reference attribute type for it?

Thanks for the responses: Evgeniy: I inherited the design and I am constrained to work with what I have. If it were up to me I would have stored the data as a multivalued attribute or a system entitlement in an LDAP directory, but the design has a single string pushed to a database, so that is what I need to manage. Aaron: I hear you about the information about this being a bit thin on the ground. I cannot even find anything to say that MS does not support modifications to the database. The questions I would really like answers for are - Why was this changed between ILM and FIM? - Why is the change not documented? - Will it break if I change the type of the field that is causing me issues?

I don't think you are going to find any answer to the first two of your three questions. But, I can tell you that modifying anything within the SQL database that FIM backends into will null any support from Microsoft for any issue you have with FIM, so I would recommend not doing it. I think the right thing to do is to create a multi-valued attribute as was suggested by Evgeniy... I think that will probably also make it easier to deliniate your requirements from that attribute -- but on the flip side, all enterprises are different, so I am sure you have the right answer. Good luck,Aaron Sankey, Avanade