Deploying DeliverPoint 2010

This section provides an overview of the installation and upgrading of DeliverPoint 2010 for Microsoft® SharePoint® 2010. It is essential to read this section of the online documentation and complete the steps in the Installation Steps section, before you can use DeliverPoint. Information on using and administering DeliverPoint can be found later in the documentation.

To successfully deploy DeliverPoint within your organization, you will need to complete the following steps:

• Plan the use of DeliverPoint within your organisation.
• Plan the installation of DeliverPoint.
• Install DeliverPoint

If you have any questions related to this documentation or the DeliverPoint product, please contact Lightning Tools by clicking Submit Support Ticket on Lightning Tools web site.

Installation Planning

LightningTools provides an installation wizard to install DeliverPoint binaries, and a configuration wizard to configure DeliverPoint. You will then need to complete some post configuration tasks before you can fully use DeliverPoint. During this process you will require access to:

• An instance of Microsoft® SQL Server®
• Your Microsoft® SharePoint® farm.
• Active Directory®.
  

!In a production environment you will need to raise a change request to install DeliverPoint.

Database server

DeliverPoint 2010 uses Microsoft® SQL Server® as the repository for both Active Directory® and SharePoint® permission information, retrieved using the two DeliverPoint interrogation SharePoint® timer jobs. DeliverPoint supports Microsoft® SQL Server® 2005, 2008, 2008 R2, and 2012. Using any other database platform such as Oracle® or SAP® is NOT supported.

The main reason for using an SQL Server database, is performance and scalability. DeliverPoint stores object information in a database rather than work with your SharePoint production databases in real-time is to increase performance of the application. In larger farms, real-time interrogation of the farm in order to commit an individual administrative action could be too costly in terms of I/O activity, memory, and processor utilization on the SharePoint servers.

The DeliverPoint database holds minimal information about the user, such as, account login name, and display name, but it does not store account passwords. Hence, from a security perspective, there is no need to encrypt the database nor should the existence of the account information in the DeliverPoint database be viewed as a security vulnerability since the DeliverPoint database cannot be used for logon purposes. Some of the SharePoint databases contain the same information, for example, the UserInfo table in the SharePoint content database or the SharePoint profile database associated with a User Profile service application. Having another database contain a copy of the same information does not increase security vulnerabilities, that you need to consider.

When you execute the DeliverPoint Configuration Wizard, you provide the name of the SQL Server and the name of the DeliverPoint database. The DeliverPoint configuration wizard then creates the DeliverPoint database. The DeliverPoint database does not need to be created on the same SQL Server instance as the SharePoint databases. Most companies have naming conventions for their databases and when a company has multiple servers running SQL Server, guidelines as to where databases should be created. Therefore when you install DeliverPoint in your SharePoint production and integration test environments, you should contact your database administrator (DBA), who will give you the name of the SQL Server and the name for the DeliverPoint database you should use.

You need to provide the DeliverPoint Configuration Wizard with an Active Directory user id, known as the DeliverPoint Service Account. On the computer where you want to create the DeliverPoint SQL Server database, the DeliverPoint Service Account must be a member of the following SQL Server roles:

• securityadmin fixed server role
• dbcreator fixed server role
  

Once the DeliverPoint database is created, these two server roles can be removed from the DeliverPoint Service Account. If you want to run Windows PowerShell® cmdlets that affect the database, the account that is used to run the cmdlets must be a member of the db_owner fixed database role for the database.

Go to top →

SharePoint server

The Microsoft® SharePoint® 2010 related components of DeliverPoint 2010 are packaged as a SharePoint farm solution, and therefore cannot be install in Office 365™. DeliverPoint uses Windows® Installer service to copy the DeliverPoint binaries to a specified location and creates a shortcut to the DeliverPoint configuration wizard on the Start Menu. The configuration wizard creates the DeliverPoint database, adds and then deploys the DeliverPoint SharePoint® farm solution. Then the DeliverPoint user interface (UI) feature is activated for each Web Application and three SharePoint® timer jobs created: two interrogator timer jobs and Job Execution timer job. As DeliverPoint is not implemented as service application, and DeliverPoint isn’t targeting a specific web application, then the timer jobs are associating with the Central Administration Web Application.

You only need to run the DeliverPoint 2010 MSI and the DeliverPoint Configuration Wizard on one SharePoint server. Lightning Tools recommend these are executed on the server which is hosting the SharePoint 2013 Central Administration web site. All files, such as DeliverPoint _layout pages, are distributed to each SharePoint server via SharePoint’s solution deployment mechanism.

To install or upgrade DeliverPoint 2010, you need full access rights to the SharePoint farm configuration database, and therefore LightningTools recommend that you use the SharePoint farm administrator account to install DeliverPoint. You will also need an Active Directory user account for the two interrogator timer jobs. This account will need full access to each Web Application where you want to use DeliverPoint.

*Note you need to use the same security context to uninstall DeliverPoint that was used to install DeliverPoint. Ensure you record the account used to install DeliverPoint so that if you need to uninstall DeliverPoint, you can use the DeliverPoint configuration wizard to uninstall DeliverPoint. DeliverPoint can be uninstalled manually using any security context.

Active Directory and SharePoint Interrogation

DeliverPoint interrogates both Active Directory and the SharePoint farm, using two SharePoint timer jobs:

• AuthStoreInterrogation. All Active Directory domains and Forests registered with DeliverPoint 2010 will be fully interrogated. The information is extracted, using the DeliverPoint Service Account, in a read-only fashion and the pertinent information, such as, Discover Object Permissions to show Domain Group membership when an account is added to SharePoint via nested Domain Groups, is stored in the AuthMember and AuthMemberOld tables in the DeliverPoint database. As the DeliverPoint Service Account is an Active Directory user account, and any Active Directory user account has read only access to Active Directory, no special Active Directory configuration is needed for the DeliverPoint Service Account. However you should verify that the ports 3268 and 389 are open in the firewalls of your SharePoint server(s) and your Active Directory server(s).The load placed on your domain controllers is not substantial.
  
  Additionally, DeliverPoint 2010 also supports Forms Based Authentication (FBA) stores. DeliverPoint 2010 automatically discovers whether Web Applications are configured to use FBA stores and proceeds to gather all the necessary information for the interrogation, efficiently crawling and obtaining users and roles information from FBA stores.
  
  Note You can use the standalone program, DPChecker, to check your interrogate configuration prior to installing and configuring DeliverPoint.
  
  
• SharePointInterrogation. DeliverPoint interrogates all SharePoint content databases in the SharePoint farm using the SharePoint Object Model (OM) and Application Programming Interfaces (API’s) and extracts, in a read-only fashion, the pertinent information needed for DeliverPoint to perform functions across an entire farm. The SharePoint content databases are not changed or read directly during the interrogation process. As the interrogation process moves through the farm, the process will interrogate an entire Web Application’s contents before moving on to the next Web Application. In other words, the interrogation process performs a deep dive crawl on all the managed paths, site collections, and sites (webs) existing in the Web Application before moving on to the next web application. The extracted information is placed into the DeliverPoint database. The DeliverPoint Service Account is used to interrogate all Web Application on your SharePoint farm, therefore you should configure a Full Control policy for the DeliverPoint Service Account on all Web Applications.
  

The interrogation of both SharePoint and Active Directory is subject to physical network limitations, for example, a domain controller only accessible over a low-speed WAN will take longer to crawl than a single-server setup. Also, the length of time that it takes for DeliverPoint to interrogate SharePoint is dependent on the number of objects (site collections, webs, lists, etc.) rather than the size of the content databases. A farm with five million objects will take longer to interrogate than a farm with five thousand.

*Note Domains may be excluded from the Active Directory interrogation to improve interrogation performance.

You cannot use DeliverPoint until a full crawl of both Active Directory and SharePoint is complete. Lightning Tools recommend that you complete this initial full crawl when DeliverPoint interrogation will not have a detrimental affect on other processes which need Active Directory and SharePoint access, such as, user profile synchronization or full crawls of SharePoint content sources. Lightning Tools recommend that you schedule full crawl interrogation to occur at night or another time that suits the SharePoint load, to mitigate any performance concerns you may have if you choose to execute the integration during business hours. Once the initial full crawl of both Active Directory and SharePoint is complete the two integration timer jobs can be configured for incremental crawls.

There are two types of interrogation – incremental and full, which can be selected using the SharePoint 2010 Central Administration web site, DeliverPoint Configuration, TimerJob Settings page.

• Full interrogation clears the related tables in the DeliverPoint database and then crawls all objects.
• Incremental. An incremental interrogation crawls all objects found to have been changed since the last interrogation. For the SharePoint interrogator, the SharePoint Change Log is used to determine whether or not to crawl a given object.
  

The AuthStoreInterrogation timer job is configured by default to run weekly on a Saturday at 2 a.m., and the SharePointInterrogation timer job is scheduled to run daily, starting every day between 2 a.m. and 4:45 a.m.

*The timer job schedules can be modified to meet your needs.

Go to top →

DeliverPoint Job Execution timer job

DeliverPoint 2010 submits a job when a user commits an operation using the DeliverPoint 2010 interface. These jobs are then processed by the DeliverPoint Job Execution timer job, by using information in the DeliverPoint database and then using the SharePoint APIs to perform the actions against the objects in the SharePoint databases. The DeliverPoint Job Execution timer job is scheduled to run every 5 minutes.

*The DeliverPoint Job Execution timer job schedule can be modified to meet your needs.

Go to top →

← Introduction
Performance Testing Scenarios →
Installation Steps →