User Registration Configuration List Settings

User Registration Configuration List Settings

Return to Overview of Configuration
These settings involve the Configuration list, which is used by User Registration Accelerator to determine who is permitted to create an account and where that account is created.
ConfigListSettings.jpg
Step Action Result
1. Allowed E-mail Address List This is the Configuration list that is built when you installed the web part.
2. Allowed E-mail Address List View Select from the drop down, the view of the Configuration list to use as the default view when determining an allowed E-mail address.
3. Allowed E-mail Address Column This is the column of the Configuration list that contains the allowed E-mail addresses.
4. SharePoint Group Column This is the column of the Configuration list that contains the SharePoint group a certain email address’ new account should be assigned to.
5. Organization Unit Column The column of the Configuration list that contains the Organizational Unit a certain email address’ new account should be assigned to.
6. Security Groups Column The column of the Configuration list that contains the Organizational Unit a certain email address’ new account should be assigned to.

Release Notes for User Registration Accelerator

Release Notes for User Registration Accelerator

NOTE: Release Notes will open in a new browser tab

WSSv3/MOSS SharePoint 2010 SharePoint 2013 SharePoint 2016
Release Notes Release Notes Release Notes Release Notes
Microsoft ended mainstream support for SharePoint 2007 in October 2012. See Microsoft’s Lifecycle Support Policy.
At that time, Bamboo stopped enhancements to our SharePoint 2007 product line, but continues to provide support and bug fixes to customers with active support contracts until October 2017. Previously purchased licenses will continue to function after October 2017, but support for these products will end, and no additional bug fixes will be provided beyond that time. Bamboo plans to cease selling new licenses and annual support contacts for its SharePoint 2007 products in October 2016 to ensure customers will be eligible to receive support for at least one year after purchase.
Microsoft plans to end mainstream support for SharePoint 2010 in October 2015. See Microsoft’s Lifecycle Support Policy. At that time, we will stop any enhancements for our SharePoint 2010 product line but will continue to provide support and bug fixes for our SharePoint 2010 products to customers with active support contracts until October 2020. Previously purchased licenses will continue to function after October 2020, but support for these products will end, and no additional bug fixes will be provided beyond that time. Bamboo plans to cease selling new licenses and annual support contacts for its SharePoint 2010 products in October 2019 to ensure customers will be eligible to receive support for at least one year after purchase.

Visit our website where you can get the latest info about each of our products for SharePoint 2013.

A separate installation package and license key is required for SharePoint 2013 deployment. For additional details, review the following knowledge base articles:

Bamboo Solutions has also begun releasing products for SharePoint 2016. For additional details, check the product release notes in the link above, or contact us.

For details on migration, see the Knowledge Base Article “Migrate Bamboo Products from SharePoint 2013 to SharePoint 2016”

Understanding Bamboo Releases:

  • Bamboo offers Trial, Basic and Premium support.
    • Free Trial support expires after 30 days.
    • For more information about Basic and Premium support, please see the Support Plans page.
    • There may be a fee to upgrade from a major version to another.

See Also:

Overview of User Registration Accelerator

Overview of User Registration Accelerator

Components of the Accelerator

Once installed, the SharePoint User Registration Accelerator gives you the ability to create a central, public-facing location for new users to request their own SharePoint account. The Accelerator consists of three parts, each of which handles a different aspect of the user account creation process.

UserRegToolpane.jpg The User Registration Web Part (URWP) is the only part of the Accelerator accessible to the public. It’s through the Web Part that users enter their account information and ultimately make an account creation request. Additionally, the Web Part’s tool pane contains several administrative options, such as the location of the Configuration List, administrative login credentials, language, and formatting options for confirmation emails.

ConfigList2013.jpg The User Registration Configuration List is automatically created when User Registration Accelerator is added to a page. This list contains any and all custom rules regarding the creation of user accounts, including which domains and email addresses are permitted to register new accounts. Rules are enforced in the order in which they’re listed, so if the email address of an account creation request meets multiple criteria, it will use the first rule in the list it matches.

RequestList.jpg The Request History List contains a full record of all account creation requests, along with other information, including email address (to prevent duplicate account creation) and the status of the request (successful, failed, or pending).

Both lists are automatically created when you add User Registration Accelerator to a page; they are used by the web part and contain the different account creation rules and all account creation requests that have been made, respectively.

The Account Request Process

Here’s what happens when a visitor to the site containing User Registration Accelerator makes an Account Request.

  1. The email address submitted by the user is checked against the Configuration List.
    • If it fails to match any of the rules there, the request is denied.
    • If it matches a rule, the request procedure continues – if the account request is ultimately successful, the new account will be created according to the specifics of the matching rule.

NOTE: These rules are checked in the order they are stored in the list, so that if the supplied email address falls under multiple rules, User Registration Accelerator will use the earliest one listed.

  1. Next, the email address is checked against the Pending Request list.

    • If it does not match any of the addresses stored on the list, it is confirmed as an original request, and the request procedure continues.
    • If it does match an existing address, the request is denied.
  2. Once the system has determined the email address has not already been used to create an account, an email message is sent to the submitted address to confirm its authenticity. At this point, the request is “pending”.

  3. When a user clicks the link contained within the authentication email, the new account is created, based on the specifics contained in the Configuration list (determined in Step 2).

  4. Finally, a confirmation message is sent to the account’s email address, containing the new user name and password.

Overview of Configuration Tool Pane

Overview of Configuration Tool Pane

UserRegToolpane.jpgAfter you first add the web part to a page, you will need to edit the web part so you can configure the options within the tool pane window. There are several that are showing in collapsed view that you will need to expand and set up. Click the topics linked below to learn how to configure that section of the web part.

The Account Request Process

Here’s what happens when a visitor to the site containing User Registration Accelerator makes an Account Request.

  1. The email address submitted by the user is checked against the Configuration List.
    • If it fails to match any of the rules there, the request is denied.
    • If it matches a rule, the request procedure continues – if the account request is ultimately successful, the new account will be created according to the specifics of the matching rule.

NOTE: These rules are checked in the order they are stored in the list, so that if the supplied email address falls under multiple rules, User Registration Accelerator will use the earliest one listed.

  1. Next, the email address is checked against the Pending Request list.

    • If it does not match any of the addresses stored on the list, it is confirmed as an original request, and the request procedure continues.
    • If it does match an existing address, the request is denied.
  2. Once the system has determined the email address has not already been used to create an account, an email message is sent to the submitted address to confirm its authenticity. At this point, the request is “pending”.

  3. When a user clicks the link contained within the authentication email, the new account is created, based on the specifics contained in the Configuration list (determined in Step 2).

  4. Finally, a confirmation message is sent to the account’s email address, containing the new user name and password.

Outgoing E-mail Settings

Outgoing E-mail Settings

Return to Overview of Configuration
These settings affect how user Registration Accelerator sends automated system email regarding account creation.
Outgoing.jpg
Step Action Result
1. SMTP Server Name Enter the SMTP server name from which the email is to be sent.
2. From Address (Notification Email) This is the address that will emails will be coming “from” and which will appear on the email.
3. Use SMTP Secure Authenticated Connection To send confirmation and approval emails through a secure SMTP connection, you’ll need to provide User Registration Accelerator with the SMTP account information, including User ID, Password, and Port.
(The next section will display when you click the box.)
4. User ID Enter the User ID of the secure email account.
5. Password Enter the Password for the secure email account.
6. Port Enter the port number which the secure email account uses.

Migrating User Registration Solution Accelerator from SharePoint 2007 to SharePoint 2010

Migrating User Registration Solution Accelerator from SharePoint 2007 to SharePoint 2010

Be sure you have at least the Minimum SharePoint 2007 Product Release (shown in the table below) installed before migrating. If not, upgrade your Bamboo product release before migrating. For more information, see Upgrading your Bamboo Web Part. Also, the target SharePoint 2010 farm requires at least the Minimum SharePoint 2010 product release shown.

Icon-Warning IMPORTANT: When migrating from SharePoint 2007 to SharePoint 2010, you MUST select the option to change existing SharePoint sites to use the new user experience. Your Bamboo products will not perform as expected with the old look and feel.

Minimum SharePoint 2007 Product Release 1.3.2 Minimum SharePoint 2010 Product Release 10.3.11
In-Place Upgrade
Issues The User Registration Accelerator settings are lost when migrating to SharePoint 2010.
Resolution The SharePoint Administrator must re-configure the User Registration Accelerator to continue using the product.
Database Attach Upgrade Method
Issues The issues for this method are the same as those noted for the In-Place Upgrade method.
Resolution The resolution for this upgrade method is the same as that noted for the In-Place Upgrade method.

Migrating User Registration Solution Accelerator from SharePoint 2010 to SharePoint 2013

Migrating User Registration Solution Accelerator from SharePoint 2010 to SharePoint 2013

Be sure you have at least the Minimum SharePoint 2010 Product Release (shown in the table below) installed before migrating. If not, upgrade your Bamboo product release before migrating. For more information, see Upgrading your Bamboo Web Part. Also, the target SharePoint 2013 farm requires at least the Minimum SharePoint 2013 product release shown.

Icon-WarningIMPORTANT: When migrating from SharePoint 2010 to SharePoint 2013, the Database Attach Upgrade Method is the only method supported.

Minimum SharePoint 2010 Product Release 10.3.24 Minimum SharePoint 2013 Product Release 10.3.33.2013
Database Attach Upgrade Method
Issues The User Registration Accelerator migrates without any errors or additional steps required.
Resolution N/A

Localize Bamboo Applications or Custom Columns

Localize Bamboo Applications or Custom Columns

Overview of the localization process for Bamboo Products

Bamboo applications and custom columns are slightly different than web parts when it comes to localizing/translating. The user interface isn’t confined to a web part, but can exist as site definitions or other custom pages. For example, the configuration of a Bamboo custom column is within the SharePoint list settings area.
The text strings that require translation are located in different files than the strings that appear in a web part.

Changing the language or text for an application or custom column is a multi-step process:

Top

About the Language Files

Text displayed in a Bamboo application may be included in one or both of the following locations:

  • Provisioning Resources. These resources are located in the 12, 14, or 15 “Hive”, in the Resources folder. The number of the Hive depends on the version of SharePoint you are using (e.g., SP2007 has a 12 Hive, SP2010 has a 14 Hive, and SP2013 has a 15 Hive). 14Hiveresources.jpg

    The Bamboo.*.resx files include text used in site features, site definitions, list definitions, and other provisioning resource elements. Any changes you make in these files will apply to new product instances only.

  • Application/Runtime Resources. These are also located in the 12, 14, or 15 Hive, but in the CONFIGResources folder.The Bamboo.*.resx file in the CONFIG folder is different than the one included in the Resource folder.14HiveCONFIGResources.jpg This one includes text used in application pages, custom site menu actions, navigation elements, and other runtime resources. Any changes you make will apply to new and existing product instances only.

In each location, there may be multiple versions of Bamboo.*.resx files with identical content. The different files are provided for English (en-US), German (de-DE), French (fr-FR), and Spanish (es-ES). The content of all files is in English until you translate it to your language. If your site is configured to use a language that does not have a corresponding Bamboo product .resx file, copy an existing file and rename it to include the culture name for that language pack. For example, create a file for Italian by saving the default file as Bamboo.[Product].it-IT.resx. Make your changes to this new file. If your site is configured to use a specific language but you do not have a culture-specific file, the product will use the default Bamboo.[Product].resx file instead.

Icon-WarningIMPORTANT: If you customize one of the default resource files provided with the product, your changes will be overwritten when you upgrade.

To avoid losing customizations, copy the customized file to a different location (not the same folder) before upgrading. After the upgrade is finished, compare the new file with your customized file to incorporate any new entries. Then copy the merged file to the Resources folder. Culture-specific files created for languages that are not provided with the product will not be overwritten during an upgrade, but you still need to incorporate new resource entries.

Top

Editing text in resource files

Icon-WarningIMPORTANT: Before making any changes, back up your original file to a different folder.

To change text in a resource file, open it in a text editor and locate the text you want to change. Editable text is usually found between the <value></value> tags, as shown in the screen shot below. Do not modify the data tag. If you want to remove text completely, delete only the text; do not delete the <data> or <value> entries from the file, or the server will display an error message. In the example below, the editable text is highlighted in gray.

Common_resxEdit.jpg

When you are finished with your changes, save the file and copy it to the appropriate Resources *folder on *all Web front-end servers in your SharePoint farm. Follow the instructions below to make your changes take effect.

Top

Applying Language File Updates

To apply changes to Provisioning Resource Files:

If you modified the provisioning resources file, apply your changes by restarting Web services with the following command on all Web front-end servers.

iisreset

NOTE: changes to provisioning resources affect new instances of the Bamboo product only; existing instances of the product are not updated.

To apply changes to Application/Runtime Resource Files:

If you modified the application/runtime resources file, apply your changes by executing the following stsadm command on all Web front-end servers. This command copies the updated resource file to the App_GlobalResources folder of each Web application. Changes apply to existing product instances and any new instances you create.

stsadm -o CopyAppBinContent

NOTE: Changes apply to EXISTING product instances AND any new instances you create.

Layout and Language Settings

Layout and Language Settings

Return to Overview of Configuration
These settings determine the CSS/HTML style settings of the Web Part itself, along with the language of the tool pane.
Layout.jpg
Step Action Result
1. Style Select “default” to use the built in style, or ”custom” to use your own. If “custom” is selected, you can edit the HTML of User Registration Accelerator by clicking the Source Edit button, or edit the CSS by clicking the CSS Edit button.
2. Show optional user information section When this option is selected, User Registration Accelerator will include fields for users to enter optional account information (address, contact information, etc.).
3. Language Determines the language file used the in User Registration Accelerator tool pane. For more information on Language and Translation settings, see Localize Bamboo Web Parts for your Language.