This chapter is from the book
This chapter is from the book
This chapter is from the book
System Settings
The System Settings area of Central Administration contains crucial settings that you need to plan and carefully control modification of. Most of the system settings affect all web applications and associated users in your server farm. System Settings is divided into three sections:
- Servers
- Email and Text Messages (SMS)
- Farm Management
Servers
The Servers section of System Settings gives you, at a glance, visibility into your server farm topology, including your application services topology. It also provides the SharePoint configuration database version and SQL Server name(s).
Servers in Farm
From the Manage Servers in This Farm link, you can see all the servers in your farm, as contained in the configuration database. You’ll see five headings beneath the configuration database information:
- Server—Lists all servers in your server farm. You can click the Server text itself to sort the list alphabetically.
- SharePoint Products Installed—Displays the relevant SKU information about that server.
Services Running—A valuable tool when discovering and troubleshooting a SharePoint Server farm. You are able to quickly see where specific application services are provisioned. If you were troubleshooting the User Profile Service, for example, you could find what server or servers were processing that data. You can then go to the relevant server and begin troubleshooting.
NOTE
Figure 2.5 shows the services provisioned on a server and not necessarily the current status. It’s possible that a service is nonfunctional and still shows as running on this screen. It’s also possible that a server is completely offline because that status is not displayed.
FIGURE 2.5 All farm members and started services can be seen on the Services on Server management page.
- Status—Displays whether a server action is required or is being performed. Examples of this are service packs, language packs, and platform additions such as Project Server.
- Remove Server—Use this option if you want to remove a server’s entry in the configuration database. Use this option with caution because it is irreversible. You should need to remove a server using Central Administration only if that server is no longer operational. The best way to remove a server from a farm is using the SharePoint 2013 Products Configuration Wizard on the server you want to remove and then selecting to disconnect it from server farm.
)
Manage Services on Server
The Manage Services on Server page is used to stop and start farm server services. These services are not Windows Server services. Although turning one of these services on or off in the configuration database might result in a Windows Service being turned on or off, the consequences of mistakenly stopping a SharePoint service are much worse than stopping a Windows Server service. For example, turning off the SharePoint Server Search service will update the configuration database and remove all entries related to that search server. Therefore, all relevant search content, such as the index, will be deleted, and the associated Windows Server service will be stopped. Basically, everything you start or stop in this screen is making configuration database changes. The timer job will subsequently pick up those changes from the database and modify application services accordingly.
The Manage Services on Server page also controls where processing of information is performed in your server farm. For example, you could have multiple servers in your farm performing the task of Managed Metadata Services. This allows for scalability of processing because it allows each server in the farm to process different server farm services. To stop or start services, you can select the Start or Stop hyperlink. If configuration is required to start, you will be automatically taken to the configuration screen. Don’t confuse these services with service applications. Although service applications might use a service on a server, service applications apply across a server farm and exist at a level above services on the server. Always verify you are modifying the correct server, as shown in Figure 2.6.
)
FIGURE 2.6 Verify you are configuring the correct farm before starting or stopping services.
Email and Text Messages
SharePoint Server 2013 provides many ways to communicate via email and mobile text messaging. Pay close attention to the configuration of both incoming email messages and text messages (SMS). There are possible cost and security issues associated with external, automated farm communications.
Outgoing Email Settings
Outgoing email is primarily used for system alerts. Alerts allow users to be updated when an object changes, such as a list or a document. Depending on the users’ choice, they can be alerted immediately, daily, or weekly. Additionally, the system generates messages for workflows and other system content that leverages outgoing email. To configure outgoing email, you need to specify an outbound Simple Mail Transfer Protocol (SMTP) server, as shown in Figure 2.7.
)
FIGURE 2.7 The From address and Reply-To address values can be different.
Although the From and Reply-To addresses can be different, they usually are not. Allowing a different From address might help you with current Unsolicited Commercial Email (UCE) whitelists, for example. You can also change the character set if needed for a different language. Be sure both the SharePoint Foundation 2013 and SharePoint Server 2013 language packs are loaded for the selected language.
Incoming Email Settings
Configuring incoming email is more complex than configuring outgoing email and requires changes to both your Windows servers and Active Directory configuration. First, you must have an SMTP server loaded on the servers that will accept incoming email. SharePoint Server 2013 does not include an SMTP service, but the default Windows Server SMTP server should work quite well. In Windows Server 2008 and Windows Server 2012, you add the SMTP server from Server Manager, Features.
After you have installed the SMTP service, or identified an external SMTP server to use for incoming email and have created and delegated permissions in Active Directory, you can proceed with configuring your farm’s Incoming Email settings. If you have enabled the Directory Management Service, distribution lists can be created automatically when enabled for SharePoint Server sites. Creating distribution lists automatically creates a distribution list in Active Directory and keeps it synchronized from SharePoint Server to Active Directory. Doing so allows users to easily send email to SharePoint Server groups when needed.
An additional function of the Directory Management Service is that it automatically creates an Active Directory contact when email–enabling a list or library. Although it is not required or always desired, you can have the email address available in the Global Address List (GAL) after email-enabling a list. If you have not enabled the Directory Management Service, you must manually, or through a custom process, create an entry for each mail-enabled document library and list you want to receive email.
To configure incoming email, navigate to the Incoming Email Settings page at Central Administration, System Settings, Configure Incoming Email Settings:
- Select Yes to enable sites on this server to receive email.
- Select Automatic unless you are using an SMTP server other than the native Windows Server SMTP Service. If you are using a third-party SMTP server, be sure to define the email drop folder at the bottom of the page. Be aware that many third-party SMTP servers will not integrate with SharePoint Server 2013.
Select Yes to create a distribution group or contact, or select Use Remote if you already have an existing Directory Management Service. If you select Yes and you use Exchange Server, you must take additional configuration steps outside of SharePoint 2013:
- You must delegate permissions to an Active Directory OU to be used for the storage and management of SharePoint Server 2013 contacts and distribution lists.
- You must ensure that an A record for your SharePoint 2013 server exists in your organization’s DNS configuration.
- You must add an SMTP connector on the Exchange Server. For more information on adding an SMTP connector, see the following link: http://technet.microsoft.com/en-us/library/cc262947.aspx#AddSMTPconnector
Specify the Active Directory OU where new distribution lists and contacts will be stored. In this example we have created an OU named SharePointDMS in our Active Directory. Use the distinguished name of the container in the text box: OU=SharePointDMS, DC=contoso, DC=com. Figure 2.8 shows an example of the OU and SMTP server settings.
FIGURE 2.8 Carefully enter the path to the container specified for the Directory Management Service.
- Enter the name of the SMTP server where you will accept incoming email. This server must be a member of the server farm. The Microsoft SharePoint Foundation Timer on this SMTP server monitors the default email drop folder. When it discovers an email with a corresponding incoming email address in SharePoint Server 2013, it routes the email constrained by the list or library settings.
- You must decide whether to accept messages from authenticated users or all users. If you decide to accept messages from authenticated users, a Send-To email address must match that of a user with write access on the destination list or library.
Select whether to allow the creation of distribution lists. You can configure SharePoint Server 2013 to create contacts in Active Directory without creating distribution lists for synchronization with SharePoint Groups. If you decide to create distribution lists, you also need to decide what level of scrutiny the list names will have. You have four options when managing the creation and modification of distribution groups:
- Create New Distribution Group
- Change Distribution Group Email Address
- Change Distribution Group Title and Description
- Delete Distribution Group
Note that there is no approval option when creating contacts. Approval settings exist only for distribution groups.
You can also define the incoming email server display address. Figure 2.9 shows an example of setting the value. Be aware that only defining the display address will not route email correctly. In this example, the server name is app02.contoso.com, but the display address is contoso.com. Care must be taken to correctly route the email from the SMTP server servicing the contoso.com domain.
FIGURE 2.9 Verify that you have the routing rule on the SMTP server configured correctly to reflect the incoming email display address.
- Verify that that DNS has the correct records for routing email. SMTP and SharePoint Server 2013 both need to have the correct DNS configuration before incoming email will function correctly.
- If you are using Automatic mode, you should configure the Safe Email Servers settings. This setting can force incoming email to route through your safe mail servers that perform antivirus and antispam scanning. It can also reduce the surface area for Internet-based attacks. To specify a safe server, enter the IP address—for example, 10.1.1.200. Entering the fully qualified domain name (FQDN) of the mail server will not work.
- Click OK to complete the configuration.
)
)
Incoming email is now configured and can be enabled on your SharePoint 2013 lists and libraries. Figure 2.10 shows an example of the incoming email configuration settings for a document library on a team site.
)
FIGURE 2.10 The incoming email configuration settings of a list or library.
Configuring Mobile Accounts
The Mobile Alert feature allows users to subscribe to alerts with their mobile phones. The idea behind the functionality is that many professionals prefer to get important alerts via mobile text (SMS) rather than via email. Not all users have smart phones or smart phones that are compatible with their corporate email system. Configuring mobile alerts allows notification to almost any cellular telephone. The feature does come with some drawbacks, however. First, you must have a subscription with a third-party SMS provider. The SMS provider acts as a “man in the middle” to relay mobile messages to cellular providers. This comes at a cost. Although the future of this space is widely unknown, current prices range from $.02 USD to $.06 USD per message. You can find a list of SharePoint Server 2013–compatible providers at http://messaging.office.microsoft.com/HostingProviders.aspx?src=O14&lc=1033. There is a constantly changing list, and your costs will vary based on your geographic location and volume of prepaid SMS alerts.
To configure SharePoint 2013 to support mobile accounts using Windows PowerShell, take the following steps:
- Confirm that the farm account has permissions to access the Internet to send alerts.
- Obtain the root certificate for the service provider’s HTTPS web address.
Import the service providers root certificate and create a trusted root authority using Windows PowerShell:
Import a trusted root certificate:
- Click Start, Run, and enter MMC; then click Enter.
- In the Microsoft Management Console, click the File tab and select Add/Remove Snap-in.
- Select Available Snap-ins, Certificates, Add.
- In the Certificates Snap-in Wizard, select Computer account and click Next.
- Click Local Computer.
- Click Finish.
- In the Add or Remove Snap-ins Wizard, click OK.
- In the console tree, expand the Certificates node.
- Right-click the Trusted Root Certificate Authorities store.
- Click All Tasks, Import.
- In the Certificate Import Wizard, click Next.
- Browse to the location of your trusted root authority certificate, and click Next.
- Select the option button for Place All Certificates in the Following Store, and browse to the Trusted Root Authority; click Next.
- Click Finish to complete the wizard.
Create the trusted root authority by clicking Start, All Programs, Microsoft SharePoint Server 2013 Products, SharePoint 2013 Management Shell:
- Right-click Run as Administrator.
To get the root certificate, enter the following command:
$cert = Get-PfxCertificate <ObtainedCertificatePath>
Create the trusted root authority using the following command at the Windows PowerShell command prompt:
New-SPTrustedRootAuthority -Name <Name> -Certificate <$cert>
- <Name> = name of the trusted root authority you want to create.
- <ObtainedCertificatePath> = location of the root certificate file.
Set the mobile account using Windows PowerShell:
Set-SPMobileMessagingAccount -Identity sms - WebApplication http://portal.contoso.com -ServiceURL https://yoursmsprovider.com/omsservice.asmx -UserId user@contoso.com -Password password1
To configure a mobile account from Central Administration, take the following steps:
- Import the trusted root certificate of your service provider using Windows PowerShell as described earlier in step 3a.
- Create the trusted root authority as described in step 3b.
- Navigate to the Mobile Account Settings page in Central Administration at Central Administration, System Settings, Configure Mobile Account.
- Click the Microsoft Office Online link for a list of messaging providers, and select your wireless provider’s country and region.
- Select a service provider from the list. After you have selected the provider you want to use, you will be directed to the provider’s website.
- In the username and password box, type the username and password that you received from the SMS service provider.
- Click Test Service to verify that the text service is running as expected.
- Click OK to complete the configuration.
Farm Timer Jobs
The Microsoft SharePoint Foundation Timer service runs on each server in the farm and is the master process for all timer jobs. It is not configurable—that is, it cannot be started and stopped from within Central Administration. It can, however, be restarted if you suspect a problem by going to Windows Server services from Start, All Programs, Administrative Tools, Services. It is listed as SharePoint 2013 Timer. You should not directly modify the logon account or other settings directly from Windows Server. You should restart only if necessary.
Timer jobs are created and deleted by SharePoint Server 2013 features or by developers via custom code. If your developers will deploy timer jobs to support custom code, be sure to test on an environment other than your production servers, and test for 24 hours or longer. Many timer jobs do not immediately display errors. Only time will show if the custom timer job has a problem. Third-party products that create timer jobs should be tested to the same level as custom code. Be sure to test any custom timer jobs before a major service pack or SharePoint Server 2013 version change.
To see the currently defined timer jobs, browse to Central Administration, Monitoring, Review Job Definitions and look at the job definitions. When viewing the Service Job Definitions page, you’ll notice approximately 180 timer job definitions in your fully configured SharePoint Server 2013 server farm. This number will vary depending on the number of web applications, configured service applications, and the configuration of core operations. Figure 2.11 shows a portion of the timer jobs in the Server Job Definitions page.
)
FIGURE 2.11 Every web application you create will instantiate several timer jobs.
Some of these timer job definitions will be minutes, whereas others are hourly, daily, weekly, or monthly. The capability to easily change the timer job’s schedule from the user interface is still available, although caution should be used when modifying the default schedule because it can affect server farm and application functionality. For the most part, you should leave the timer jobs in the default state. For some timer job definitions, such as the Content Type Hub and Content Type Subscriber, you will be very tempted to increase the frequency of the timer job. Although this action will make enterprise content types available sooner and give the subscribing site collections more frequent updates, it comes with a compromise in performance. Timer jobs take both processor power and memory, so you need to weigh the benefits with the performance penalty. Figure 2.12 shows an example of changing the Content Type Subscriber frequency. Also notice that you can click Run Now. This option often negates the need for increasing the frequency of a timer job because you can force an update manually.
)
FIGURE 2.12 Click Run Now to manually start a timer job.
Although timer jobs run on every server in the farm by default, you can select a preferred server to execute timer jobs on per-content-database basis. Workflows are one of the driving factors to include this functionality. Using this example of workflows will help you understand why server timer job affinity is important.
SharePoint Server 2013 executes workflow actions on the web server that the client was connected to when started. If this workflow must wait to continue because of a scheduled time delay or inaction by the user, the SharePoint 2013 Timer service will handle the workflow execution. In a multiple web server configuration, you can set the preferred server for executing the workflow via the content database that hosts the site collection in question. To set the preferred server for timer jobs, do the following:
- Browse to the Manage Content Database page, Central Administration, Application Management, Databases, Manage Content Databases.
- Select the database you want to modify.
Select the physical server you want to associate as the preferred server. See Figure 2.13 for an example of setting affinity.
FIGURE 2.13 You can select any server farm member to be the preferred server for a content database.
)
In addition to managing the timer job, you can also check the job status from Central Administration, Monitoring, Timer Jobs, Check Job Status (see Figure 2.14).
)
FIGURE 2.14 The Timer Job Status page.
The Timer Job Status page allows you to view the status of scheduled jobs, see running jobs, and view timer job history. You’ll find this page useful when troubleshooting problems within your farm. Hung processes, such as workflows or backup and restore, can be deleted to allow for future instances. It is recommended that you not delete timer jobs when you are not sure of the consequences of that action. There is no option for you to delete platform-level jobs; this action would have dire consequences. Instead, they have replaced the delete option with a disable option. Always document your action for future reference if you delete or disable a timer job.
Farm Management
The Farm Management area, located under System Settings, is essentially a bucket for items that are associated with the configuration database or didn’t fit neatly elsewhere. The Farm Management functional areas are as follows:
- Alternate Access Mappings—Details about this configuration option can be found in Chapter 4, “Creating and Configuring Service Applications.”
- Manage Farm Features, Manage Farm Solutions, and Manage User Solutions—Details on these options are presented in Chapter 15, “Managing Apps and Solutions.”
- Configure Privacy Options—This configuration option allows you to decide whether your server farm will automatically connect to Microsoft for the Customer Experience Improvement Program (CEIP), error reporting, and external web-based help. Be careful when turning these on if you are in a secure environment. Many times, servers in a secure environment will not have outbound HTTP enabled. If that is the case, web-based help will not function.