I'm getting the "Unable to process your request" error quite a lot here. Most often it happens right after making a change to an object. I click Finish, the popup closes, the page tries to refresh, and then goes (after only a second or two) to the "Unable to process your request" page. In all cases the change I was making does in fact get made. I thought it was poor performance due to an initial bulk load, but that's finished now and it's still happening, pretty much all the time. The server is a new build and I have not yet made any changes inside the portal, apart from loading in around 40k objects. The big difference is they have forced me to put the DB on a seperate SQL server (version 2008 R2). As far as I can tell the throughput is ok - I have a 100 Mbps link and during a large export it uses 25% of it. I don't see anything in the svclog at the time the error occurs. Any ideas?http://www.wapshere.com/missmiis

I must admit that I see this behavior from time to time also. All though I can't help you any further. I'm on a separate SQL: a failover cluster with SQL 2008.http://setspn.blogspot.com

This is way more than an annoyance - I cannot get anything done. For example, I can't get to page 2 of the MPR listing. I also can't search on MPRs. If I go in a popup and click Extended Attributes I get the error. The portal is unusable! I tried disabling customerrors but I'm still getting this same error page. The only information I can find (and it's not much help) is in the IIS logs: 2010-09-14 08:26:34 10.36.8.233 POST /IdentityManagement/aspx/policy/AllPolicies.aspx - 80 - 10.36.20.130 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.0;+WOW64;+SLCC1;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729) 401 1 2148074248 1 2010-09-14 08:26:37 10.36.8.233 GET /_layouts/MSILM2/ErrorPage.aspx errorCode=0 80 - 10.36.20.130 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.0;+WOW64;+SLCC1;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729) 401 2 5 0http://www.wapshere.com/missmiis

is that the generic portal error page? if yes, i would just enable tracing and get the full stack when it happens again

Carol, For enabling tracing, the following might help: http://setspn.blogspot.com/2010/06/fim-2010-enable-advanced-error-logging.html It's a procedure of Anthony.http://setspn.blogspot.com

Yes I've already enabled all possible trace logs (and turned them off again in case they were contributing to performance problems). There were no errors or warnings relating to this. The only thing I could find was in the IIS logs, above. Any suggestions on what I should be looking for in the trace logs?http://www.wapshere.com/missmiis

mind posting a screenshot?

Of the error? It's just that generic one, as you say.http://www.wapshere.com/missmiis

http://setspn.blogspot.com/2010/06/fim-2010-enable-advanced-error-logging.html Then try this one again. I suspect you aren't editing the web.config (but web.config.bak instead) try to open a cmd prompt and do "notepad C:\inetpub\wwwroot\.....\web.config" to make sure u are opening the right file

No I've edited the web.config. I have all the svctrace log files: fimDiagnostics.svclog ILMPortal.Client_messages.svclog ILMPortal.Client_tracelog.svclog I just checked it all through yet again. I can generate the error reliably by attempting to navigate to page two of the MPR listing. I get the exact time the error page was loaded from the IIS logs. The two ILMPortal logs go completely quiet. They report thr first page of the MPRs being loaded, then nothing at all at the time of the error. In the fimDiagnostics log I just have the following information messages: Post Processing Manager is checking Requests for completion. The scan to check for Completed Requests started with Request Key '0' and ended at Key '0'. Post Processing Manager has finished checking Requests for completion. HostActivator refreshing active host cache. HostActivator finished refreshing active host cache. That's all. http://www.wapshere.com/missmiis

Carol, I'm gonna curse here: have you tried rebooting your FIM Portal server? I had exactly the same issue, MPR's being very resistant to small updates. I have been rebooting more often: everytime I add a new attribute to the portal scheme.... (http://setspn.blogspot.com/2010/06/error-when-exporting-to-fim-ma-failed.html ) And now I don't suffer it. I think it's something which sneaks into your setup somehow. Ofcourse this is not a permanent solution, but it would be interessting information. It's odd that this doesn't appear in any logs. Regards, Thomashttp://setspn.blogspot.com

I have rebooted this morning. It's not just the MPRs anyway - I'm seeing this error all over the portal. this is just the way I'm reproducing it at the moment. http://www.wapshere.com/missmiis

When encountering at MPR's I couldn't simply open them at moments, when encoutering at attribute creatoing (schema extension) It throw the error, but the change was made. Just like you stated. I'll check my eventlogs, perhaps I find anything, but due to the amounts of reboots It's been a few weeks since I saw that error.http://setspn.blogspot.com

this is really weird... i personally haven't had any issue disabling the error page and get the stack. not being able to do so is a serious support blocker. is ur environment private? possible if i TS to take a look? maybe Live Meeting or desktop sharing through remote deskop... or remote assistance? i will be free around PST 12pm. you can ping me on communicator (aho@microsoft)

I've sent an email to what I hope is your email address.http://www.wapshere.com/missmiis

got it

A clue at last! Accessing the Portal via the server ip address from a workstation seems to work (I can naviagtes through all the MPR pages anyhow, for the first time today). Accessing the Portal on the FIM server using its ip address still gives the same error page. http://www.wapshere.com/missmiis

That would point somehow to Kerberos. Allthough I can't entirely believe it as I'm fairly confident my setup is configured OK Kerberos wise. You could, just for fun, enable Kerberos Logging on your portal server and/or client: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters DWORD LogLevel Value 1 (0 to disable again) Active immediately. If you want more info on the regkey: http://setspn.blogspot.com/2010/06/kerberos-basic-troubleshooting-tip-4.html http://setspn.blogspot.com

Could kerberos affect access on the fim server itself? The server and the account I'm using are all in the same domain.http://www.wapshere.com/missmiis

What I mostly see with Kerberos related problems: it works or it doenst works. The only time I encounter "it sometimes works and sometimes doesnt works", if the users in question are member of a lot of groups. Then you can get a token which is larger than what lsass and/or IIS (maxRequestSize) allow. But I'm not sure you are suffering something like this. This would definately show with stack traces and your users would have other issues as well. Your IIS logs states "401" which is "unauthorized" I think. You could run a wireshark trace on your portal while reproducing the issues from a client. Id be mighty interessed in getting my hands on such a trace. Perhaps this is relevant: http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=58 It explains how to change to logging regarding the userfriendly errors. Not sure you got it right. It's been a while since I tried that myself... http://setspn.blogspot.com

Carol, any updates?

I'm only at this customer two days a week so will be looking at it again on monday. Thanks!http://www.wapshere.com/missmiis

As un update, whenever I see the message I do have errors, so we're probably having different issues. So it's probably not relevant for you, but it might be for other people. I was having the following two errors: Exception information: Exception type: ArgumentOutOfRangeException Exception message: Specified argument was out of the range of valid values. Parameter name: utcDate Exception information: Exception type: HttpException Exception message: Request timed out. Both in the event log and the customized IIS error pages. The first one is caused by a timedifference on the client and the portal. We have our PDC configured to sync with an external source. To do this we have a GPO which only applies to the PDC (using a wmi filter). However during transitioning of the GPO's the filter got set to the wrong policy so time drifted. Luckily it's a lab environment. I hope to find a solution for the second one in the near future. And now back to your issue! Get us some more information :) Thanks to Anthony for pointing me to the time difference. http://setspn.blogspot.com

At the moment I'm just accessing the portal via its ip address. It won't be going into prod for a while yet so I've been working on other priorities. Will have to get back to it at some point though - it's not much use if everyone has to use the ip address!http://www.wapshere.com/missmiis

At the moment I'm just accessing the portal via its ip address. It won't be going into prod for a while yet so I've been working on other priorities. Will have to get back to it at some point though - it's not much use if everyone has to use the ip address! http://www.wapshere.com/missmiis Accessing the portal via IP means you're doing NTLM not Kerb which may be indicative of a Kerb issue given the 401s...My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

You said you altered the web.config file to enable some better error logging, are you sure you did it correct? You really should see an stack trace alike error... Anthony referenced the article earlier, are you sure you: set callstack to true set customerrors to off made sure "ilmerrors" is commented (between <!-- and -->) Combine this with the Kerberos Debug logging on the client/server, and you should be able to see what's going wrong.http://setspn.blogspot.com

This was from a while ago but I still don't have a solution. Customer looking to start using the Portal in the new year so I'd like to get this solved. To recap: portal works properly when accessed via ip address. When accessed via server name I frequently get "Unable to process your request. Please contact your help desk or system administrator." Typically I will get this when trying to list something - like doing a Serahc on the Users page. Just now I searched and got one page of users, but when I tried to go to the second page I got this error. I did enable Kerberos logging and I see this error, which is actually referring to the SQL server that hosts the FIMService database: A Kerberos Error Message was received: on logon session Client Time: Server Time: 14:58:9.0000 11/29/2010 Z Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN Extended Error: Client Realm: Client Name: Server Realm: mydomain.NET Server Name: MSSQLSvc/sqlserver.mydomain.net:60000 Target Name: MSSQLSvc/sqlserver.mydomain.net:60000@RCCAD.NET Error Text: File: 9 Line: e2d Error Data is in record data. So, is there supposed to be a SPN for the SQL server? When I run "setspn -L sqlserver.mydomain.net" I don't see anything. Also the FIMService database is actually in a named instance: "sqlserver.mydomain.net/FIM_PRD". Is it a concern that the named instance is not included in the server name or target name?http://www.wapshere.com/missmiis

Carol, As far as SQL and the KDC_ERR_S_Principal_Unknown is concerned: The "named instance" info should not be part of the SPN for the SQL Service. Your SPN should be of the following form: MSSQLSvc/FQDN:Port and should be registered on the account running the SQL Server Service. If it's local system, you have to add the SPN to the computer account of the SQL server. If it's a service account you have to add the SPN to the service account. More info at: http://setspn.blogspot.com/2010/06/kerberos-basic-troubleshooting-tip-2.html So, it seems you are not using Kerberos to access SQL, As a Kerberos fan I would fix this, but it's probably not the cause of your problem. Unless there are certain actions you never succeed in doing. However I'm not sure whether kerberized SQL is a requirement for FIM. I would try the above and definately try to play with the various timeouts as explained in, they might explain the unexpected behavior. http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/d7761296-6ed2-4c43-80b7-547cf4c897fb http://blogs.msdn.com/b/darrylru/archive/2010/02/02/extending-fim-timeouts.aspx I also wrote a small writeup about this: http://setspn.blogspot.com/2010/11/fim-updating-set-fails-timed-out.html Regards, Thomas http://setspn.blogspot.com

Carol, As far as SQL and the KDC_ERR_S_Principal_Unknown is concerned: The "named instance" info should not be part of the SPN for the SQL Service. Your SPN should be of the following form: MSSQLSvc/FQDN:Port and should be registered on the account running the SQL Server Service. If it's local system, you have to add the SPN to the computer account of the SQL server. If it's a service account you have to add the SPN to the service account. More info at: http://setspn.blogspot.com/2010/06/kerberos-basic-troubleshooting-tip-2.html So, it seems you are not using Kerberos to access SQL, As a Kerberos fan I would fix this, but it's probably not the cause of your problem. Unless there are certain actions you never succeed in doing. However I'm not sure whether kerberized SQL is a requirement for FIM. I would try the above and definately try to play with the various timeouts as explained in: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/d7761296-6ed2-4c43-80b7-547cf4c897fb http://blogs.msdn.com/b/darrylru/archive/2010/02/02/extending-fim-timeouts.aspx I got a blogpost I'm writing with some additional info, but it's not finished yet. Regards, Thomashttp://setspn.blogspot.com

If it was a kerberos timeout issue wouldn't I be seeing errors about that?http://www.wapshere.com/missmiis

Now you are mixing both, or my explanation wasn't clear :) The principal unknown errors is just you, as an admin, being notified that a service on that host tried to contact SQL and found out that there is no SPN for that SQL service. Hence no Kerberos AuthN can be used and it will fallback to NTLM. The other issue I have seen myself is that certain actions in FIM suffer from the default timeouts being too sharp. Like sometimes you do something in the portal, it says timed out, but if you go back it's changed anyhow. So in your case I would enlarge the timeouts so you can rule out this. And sometimes it just shows the generic error whilst in the eventlog you get ".NullReferenceException: Object reference not set to an instance of an object", as explained on my blog. So that's why I would advise to at least try the same stuff with larger timeouts. Regards, Thomashttp://setspn.blogspot.com

No harm in trying - I'll give it a go today. Meanwhile some more observations. I copied the FIMService database to another server in the same domain and the portal is working perfectly there. The big differences with the dev server are that it has SQL local and I have no SPNs configured at all. So I'm thinking either I have misconfigured the SPN for the prod server, or it does have something to do with the remote SQL. If I list the SPN for the portal service account: setspn -L s.fim-portal It does look correct: Registered ServicePrincipalNames for CN=s.fim-portal,OU=Users,OU=Admin,OU=Organization,DC=mydomain,DC=net: FIMService/FIMServername.mydomain.nethttp://www.wapshere.com/missmiis

Carol, What do you mean with the "portal service account". Is "s.fim-portal" the user which is configured in IIS as the application pool identity?" If it is, it should, if you want the portal to be kerberos enabled, Have an SPN like this: HTTP/portalfriendlyurl.mydomain.net Be trusted for delegation to FIMSERVICE/FIMServername.mydomain.net If it also the user used to run the FIM Service under, then the SPN FIMService/FIMServername.mydomain.net can remain in place. If you got an other user running your FIM Service, I think you got things mixed up. As the FIMService SPN has to be added to the account running the FIMService. SPN are in fact a way to define an "access-point" to a service. Perhaps very badly choosen words, but it means if you got a website, your accesspoint is "Internet Explorer" which has access to the content by talking to the "HTTP" service on the Web server. The account responsible for this service is the application pool identity. For the FIM Service, not "internet explorer" is the client, but the "FIM portal". And here we are accessing a service which is known as "FIMSERVICE" and is provided by the FIM Service Account. I'm not sure whether you know all this. Regards, Thomas http://setspn.blogspot.com

The app pool identity is "NetworkService". The account I refer to is the one that the FIM Identity Manager Service is running as. I don't have the HTTP SPN because I've just been trying to use the server name - no friendly url yet. The delegation trusting was done.http://www.wapshere.com/missmiis

Carol, So as you used "NetworkService" for the app pool identity, did you trusted the FIM Service Server Object for delegation towards the FIM Service SPN? In the install guide both the Portal service account and the FIM Service service account should be trusted for delegation to the FIM Service account Can you perhaps describe the current situation regarding to your problem? As It's unclear to me whether the issue is resolved or not and in which environment. Regards, Thomashttp://setspn.blogspot.com

It's not resolved. Prod server: - FIM Sync, FIM Service and Sharepoint local - SQL DBs on a remote SQL 2008 cluster. - SPN configured for FIMService, using server FQDN, with delegation done as per installation instructions. Dev server: - Everything local, no SPN. For the prod server I can only use the portal via its ip address. If I use the server FQDN I get these "Unable to process your request" errors. Typically I get this eror when attempting to go to page two of a listing (Users, MPRs etc), or when I click on something that lauches a popup. The popup appears but all it say in "Unable to process your request. The dev server, with a replica of exactly the same FIMService DB, works perfectly when accessed by FQDN. Both servers are VMs with the same config, same OS (Windows 2008) and same versions of all relevant software. I'm pretty sure the portal was working fine on the prod server before they made me move the DBs off to the SQL cluster, but as it has only been me using it so far it's hard to say for sure.http://www.wapshere.com/missmiis

I've sent you an email, perhaps it's better If I ask my questions using MSN or something alike.http://setspn.blogspot.com

Carol, According to your original post above, your client had you use a DB on a separate server (SQL 2008 R2). It doesn't appear Microsoft has released a statement regarding support for R2 yet. There are issues with the installer. They are only officially supporting SQL 2008 SP1. See the following two other recent threads. http://social.technet.microsoft.com/Forums/en/ilm2/thread/821b1973-07f4-4fc8-856b-8b23dfc37428 http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/f6f5151f-e29e-4614-8687-c392b51be0c2

Yes - however the dev server is also 2008r2 and the same config (including same DB) works perfectly there. So if it's connected to r2 it's somehow different with remote and local SQL servers.http://www.wapshere.com/missmiis

OK I've found the problem - proxy settings on the client computer. I noticed in the IIS logs that the "client address" was not in fact my client address at all, but some other ip address. I had the FIM Portal address in "Local Sites", and I had also ticked "Bypass proxy for local addresses", but it isn't enough. I have to completely remove all proxy settings and then the Portal works. But I've lost my internet access so I don't think the users will be impressed! Note the behaviour is the same on a domain member computer. So while I now know why the Portal doesn't work I can hardly go telling everyone they have to disable their proxy settings if they want to use the Portal! I guess I'll find out if there's anything that can be done on the proxy side. BTW I think the reason it seemed to work better on the DEV server was because of the local SQL - it wasn't doing any http requests across the network to be intercepted by the proxy.http://www.wapshere.com/missmiis

Lol Carol, what a total not sexy solution :) In my customer environment we are using "Bluecoat" proxies. In the next days I'll test the behavior and provide some feedback. Mostly we work from admin stations which don't have a proxy, so we might have missed this "issue". Regards, Thomashttp://setspn.blogspot.com