Good afternoon, I sent an email as well, but thought I would post to the discussion board as well. Our deployment worked fine on our dev network but have encountered an issue when attempting to deploy to a new production site. (SharePoint 2010
with separate SQL 2008 R2 server).
Scenario: Deployment works fine and the solution is listed as deployed and usable. We add the User Request Webpart and that works. We have no special needs other than what your solution would provide. When we access the user account request
page, we are successfully presented with the request page. We submit a test request. This test request account appears in the FBA User Request Management section of Central Admin AND in the FBA User Management section of CA. Also, the account
request appears within the SQL server database for the the FBA.
So far so good ... Then, the admin goes into Central Admin and goes to the FBA User Request Management section and "edits" the user account. The account request is changed from Pending to Approved and then clicks 'OK'. Then ... POOF
... the user account request is no longer visible in the FBA User Managent section and remains ONLY in the FBA User Request Management section. Also, the account that DID appear in the SQL database is now MISSING from the database. In this scenario,
the account is no longer visible in the FBA User Management section within Central Admin and therefore cannot be assigned any roles or permissions or anything else.
Thanks for any help you may be able to hide. We have attempted this deployment MANY times with the same results and have been banging our heads for a few days now! Thanks again!
When using the Review Membership Requests feature, the Membership Request web part will create a user in the in the SQL database to essentially act as a placeholder until the account is approved. When the account is approved, that user is deleted and
recreated. So it sounds like although the delete is working in your case, but recreating the user is not working. Could you check your SharePoint log file to see if any errors are logged when you go to approve the user? Could you also post
your SqlMembershipProvider configuration from your web config - i'd like to see what options are set.
One thing to check that could possibly be causing the problem is the group that's selected in the Membership Request web part settings. Can you make sure that the group exists and that you can add FBA users to that group. Maybe also try re-selecting
it and saving the changes.
Also, I assume everything works fine if the 'Review Membership Requests' feature is turned off?
First, let me say thank you for replying to my post. Your solution is exactly what we needed, but the problems have been very frustrating ... but I am beginning to think the problems are on our end.
We looked through our logs using the ULS Viewer from MSDN. Without the viewer, the logs are difficult to decipher. After looking at out logs, we discovered something we wanted to ask you about. Can the email process within the FBA solution
crash the entire process? The reason we ask is that our logs show exceptions being "thrown" due to email failures (failure to send email). First time was due to the fact that SMTP was not configured. Second time (after SMTP configuration)
was due to us using a "test" email address in which the error reported that the exchange server "downrange" did not accept the email address as known. The third time, with a legitimate email address, the process worked as described. We do not have
an exchange server, but have an agreement with another domain for our smtp relays to work ... and the email process works.
We were assuming (probably our fault) that as long as the email address FORMAT was legitimate, the process would still work. But, even with the test email of "test@test.com", the error log showed that the exchange server rejected the email address
and the process seemed to stop. When we would approve the test account that used the fake email address, it would disappear from SQL and no longer be available for role assignment.
I understand that a real email address is needed for the process to work as needed in the real world to inform the requesting user of the status of their account, but would like to know if a "fake" email address will actually crash the process?
Thanks again for your help.
Yeah, that could be it. Things definitely won't work if the specified smtp server can't be accessed. As for email addresses, I can see only local email addresses working if the smtp isn't setup to allow relay from the SharePoint server. If
relaying is allowed though, then the mail should send (even if it doesn't get received) and the process should complete. Of course you'll have a hard time testing it with fake email addresses, as the generated password is emailed to the user.
We have determined a few more things and I thought I would post. Yes, it appears the email function failure is what is stopping the process. We have contacted the Admin for the downrange exchange server and they have not set up the connector
properly and it is not allowing any emails to be send "outside" of their domain (into the internet) from our system. So, when we enter an email address with an "outside" domain (different than ours) the SharePoint logs report an email failure and the
Account Approval process quits with the account NOT being recreated into the user database. We have tested this and confirmed this to be the issue.
We thought the same thing as you wrote "If relaying is allowed though, then the mail should send (even if it doesn't get received) and the process should complete." but our problem is that the SharePoint Server SMTP was receiving an error (and logged in
Sharepoint logs) as soon as it attempted to approve an account outside of our domain and the process does not complete. Obviously, the SMTP relay on the exchange side is not configured correctly at this time. We are working on that now.
Thanks for your help.