E-Mail Templates not found


We have the following error: If a user resets his/her password an email is sent to the user. Instead of containing the defined xslt content, the email contains the following text:

Please return to the site and log in using the following information.

User Name: <username>

Password: fy4Pf3*ih@a2vc

Where is it possible to edit this email? how do I get the standard email working?

thank you!


You can select the XSLT files that are used for generating the emails from 'FBA Site Configuration' under Site Settings.

For Membership Approved it should be set to:


Check the screen shots in the documentation for all of the values.


You can also edit the xslt's at the locations specified to change the templates.

Thats exactly what we did. Also the location link is correct. The email doesnot contain the correct content, just says:

Please return to the site and log in using the following information.

User Name: <username>

Password: fy4Pf3*ih@a2vc

Is there something we have to add into the web.config file or elsewhere?


The only place the email should come from is the xslt specified in FBA Site Configuration.  Have you opened the xslt's to see if they've been changed by anybody?  Removing and redeploying the FBA Pack should overwrite the xslt's with the default one's (or you can just copy them from the wsp, if you don't want to redeploy everything).  Note that if the locations have been changed in the FBA Site Configuration, the locations will not be reset by a redeploy.

We have edited the email templates in the physical folder (_layouts/FBA/email/... .xslt) filed under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS. Is this the correct way?

Yeah, that's the way to do it!

... but the email remains the same ...

I did some additional testing on my side to ensure nothing was broken.  All worked perfectly.

The FBA Site Configuration for the membership approved page was set to:


I edited the file:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\FBA\EMAIL\MembershipApproved.xslt

Additionally I changed the value in the site configuration to:


and edited the file:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\FBA\EMAIL\MembershipApproved2.xslt

In both cases the changes to my template where in the email that was sent.  The only thing I can suggest is an undeploy and then redeploy.  Other than that, I'm not sure what is going on.

I am facing excactly the same issue. Any luck @marvin06?


I believe what was happening earlier was that ASP.NET Membership controls were sending out their own emails standard email if their was a <mailsettings> section in the web.config. This has been fixed in version 1.3.0, so please make sure you're running the latest version of the FBA Pack.

thanks for quick reply.

I do have mailsettings section in web.config but i guess its required to send out emails. Can you share whats the fix was?

 Thank you guys,

 @ccoulson ... I just commented out the mailsettings section in the web.config of the webapplication that uses forms authentication. I still received that email and with correct content this time. I have original webapp using windows authentication and then have an forms based one that was extended from the previous one. I think I  don't need the mail settings in forms one. Correct me if I'm wrong.

Do share what/how was it fixed in 1.3.x.

didn't fully understand the    <type>:get_<propertyname> convention. :(

like the one below.  <xsl:value-of select="MembershipRequest:get_Password() "/>

Where do learn this xslt <=> .Net Object / Extension functions stuffs

re the fix: In previous versions it was depending on an error to occur while sending the mail - this would occur on a standard SharePoint installation, as a standard SharePoint installation doesn't have a mailsettings section in the web.config (email configuration is internal SharePoint, and it doesn't use the web.config settings).  The fix is to no longer depend on the error for sending the email - it's sent in all cases. Here's the change:


If you update to the latest version, it should be working with the mailsettings in your web.config - in case you need then for another 3rd party module or custom development.

re: learning the xslt, i'd say if all you want to do is modify the built in templates - just follow the example included emails and follow the conventions in them.  If you want to dig deeper, i'd say google for xslt, and msdn for the specific MS xml classes/functions.  The code for transforming the xslt is here, if you're interested in looking up the commands used:


We finally switched the solution. Thats why we didnot do further research