SharePoint 2013 Platform Options – SharePoint in Office 365

What BDMs and architects need to know about SharePoint in Office 365 deployment.

Overview
SharePoint in Office 365

 

 

 

 

 

 

 

 

 

 

 

 

 

Gain efficiency and optimize for cost with Office 365 multi-tenant plans.

  • Software as a Service (SaaS).
  • Rich feature set is always up to date.
  • Includes a Microsoft Azure Active Directory tenant (can be used with other applications).
  • Directory integration includes synchronizing account names and passwords between the on-premises Active Directory environment and the Microsoft Azure Active Directory tenant.
  • If single sign-on is a requirement, Active Directory Federation Services can be implemented.
  • Client communication over the Internet through encrypted and authenticated access (port 443).
  • Data migration is limited to what can be uploaded over the Internet.
  • Customizations: Apps for Office and SharePoint, SharePoint Designer 2013

Best for

  • Secure external sharing and collaboration (unique feature!).
  • Intranet — team sites, My Sites, and internal collaboration.
  • Document storage and versioning in the cloud.
  • Basic public-facing website.

Additional features with Office 365 Dedicated Subscription Plans:

  • Microsoft data center equipment that is dedicated to your company or organization and not shared with any other organization.
  • Each customer environment resides in a physically separate network.
  • Client communication across an IPSec-secured VPN or customer-owned private connection. Two-factor authentication is optional.
  • ITAR-support plans.

License requirements

  • Subscription model, no additional licenses needed

Architecture tasks

  • Plan and design directory integration. Two options (either option can be deployed on premises or in Microsoft Azure):
    • Password sync (requires one 64-bit server).
    • Single sign-on (requires ADFS and multiple servers).
  • Ensure network capacity and availability through firewalls, proxy servers, gateways, and across WAN links.
  • Acquire third-party SSL certificates to provide enterprise-security for Office 365 service offerings.
  • Plan the tenant name, design site. collection architecture and governance.
  • Plan customizations, solutions, and apps for SharePoint Online.
  • Decide if you want to connect to Office 365 by using the Internet Protocol 6 (IPv6)
    — not common.

IT Pro responsibilities

  • Ensure user workstations meet Office 365 client prerequisites.
  • Implement the directory integration plan.
  • Plan and implement internal and external DNS records and routing.
  • Configure the proxy or firewall for Office 365 IP address and URL requirements.
  • Create and assign permissionsto site collections.
  • Implement customizations, solutions, and apps for SharePoint Online.
  • Monitor network availability and identify possible bottlenecks.

 

Read More

Event ID 6398 – SharePoint Founation Search

Applies to: SharePoint 2013

Summary: Learn about the synchronising permissions and the errors when settings permissions for the Managed Metadata Service.

Event ID 6398, SharePoint Founation

The Execute method of job definition Microsoft.Office.Server.Search.Administration.CustomDictionaryDeploymentJobDefinition (ID b1bfbccc-c3c1-4ba4-973c-0131185fe079) threw an exception. More information is included below.

Retrieving the COM class factory for component with CLSID {0FF1CE15-0005-0000-0000-000000000000} failed due to the following error: 80070422 The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422).

Resolution

Add read access for your Default Content Access Account (that you find in the Search Service Application) in the Managed Metadata Service Application.

  1. Central Admin
  2. Application Management
  3. Manage Service Applications
  4. Select the Managed Metadata Service
  5. Click Permissions in the ribbon

Give your Default Content Access Account Read Access to Term Store

Read More

Event ID 10016 – DCOM (000C101C-0000-0000-C000-000000000046)

Applies to: Windows Server 2008

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {000C101C-0000-0000-C000-000000000046}

and APPID {000C101C-0000-0000-C000-000000000046}

to the user domainspfarm SID (S-1-5-21-1813126608-4190571182-3204100927-3160) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

SharePoint 2013 - Event ID 10016 -1

If you seethe Dcom config, security the options are all greyed out. You need to do some additional steps:

Open registry editor (run regedit.exe), browse to Hkey_classes_rootAppID{000C101C-0000-0000-C000-000000000046} right click and choose permissions.

SharePoint 2013 - Event ID 10016 -2

Choose Advanced

SharePoint 2013 - Event ID 10016 -3

Go to the Owner tab, select the Administrators (DomainAdministrators) group under Change owner to and select the replace owner on subcontainers and objects. Choose OK to close the window. You will return to the permissions window.

SharePoint 2013 - Event ID 10016 -4

Select Administrators (DomainAdministrators) and set Allow Full Control permissions. After you have done the above settings you go to Administrative Tools – Component Services. Expand Component Services, Computers, My Computer, DCOM Config. Scroll way down till you find the {000C101C-0000-0000-C000-000000000046} icon, right click and choose properties.

SharePoint 2013 - Event ID 10016 -5

Go to the security tab, select customize at Launch and Activation Permissions and choose Edit…

SharePoint 2013 - Event ID 10016 -6

Select the SharePoint Farm Account and set the Local Activation right.

Read More

Event ID 10016 – DCOM APPID (EE4171E6-C37E-4D04-AF4C-8617BC7D4914)

Applies to: Windows Server 2008

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {806835AE-FD04-4870-A1E8-D65535358293} and APPID

{EE4171E6-C37E-4D04-AF4C-8617BC7D4914} to the user ADAgent-DaaS-gMSA$ SID (S-1-5-21-971660138-580146584-2293678388-3421) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

 

The big difference with the other error is when you go to the Dcom config, security the option are all greyed out. So you need to do some additional steps:

Open registry editor (run regedit.exe), browse to Hkey_classes_rootAppID{ EE4171E6-C37E-4D04-AF4C-8617BC7D4914} right click and choose permissions.

Choose Advanced

Go to the Owner tab, select the Administrators (DomainAdministrators) group under Change owner to and select the replace owner on subcontainers and objects. Choose OK to close the window. You will return to the permissions window.

Select Administrators (DomainAdministrators) and set Allow Full Control permissions.

After you have done the above settings you go to Administrative Tools – Component Services. Expand Component Services, Computers, My Computer, DCOM Config. Scroll way down till you find the {000C101C-0000-0000-C000-000000000046} icon, right click and choose properties.

Go to the security tab, select customize at Launch and Activation Permissions and choose Edit…

Select the SharePoint Farm Account and set the Local Activation right.

Read More

Event ID 1008 – Performance Library Availability

Applies to: Windows Server 2008

Performance counters, including those built in to the operating system and those provided by non-Microsoft vendors, are combined in the Performance Library. Performance monitoring applications such as Windows Reliability and Performance Monitor use the Performance Library to identify available counters and map to counter providers. Errors accessing the Performance Library may result in application errors when expected data cannot be found, or when expected data providers are unavailable.

Event Details

Product: Windows Operating System
ID: 1008
Source: Microsoft-Windows-Perflib
Version: 6.0
Symbolic Name: PERFLIB_OPEN_PROC_FAILURE
Message: The Open Procedure for service “%1!s!” in DLL “%2!s!” failed. Performance data for this service will not be available. The first four bytes (DWORD) of the Data section contains the error code.

Resolve the installation issue

If a performance library file was not properly initialized during installation, you can reload it. Membership in the local Administrators group is required to complete this procedure.

To reload a performance library:

  1. Click Start, click All Programs, and click Accessories.
  2. Right-click Command Prompt, and then click Run as administrator.
  3. At the command prompt, type cd %SYSTEMROOT%System32 and then press ENTER.
  4. At the command prompt, type lodctr:<ini file>, where <ini file> is the .ini file for the library that you want to reload.

Verify

You can use Windows Reliability and Performance Monitor to verify that netowkr performance counters are properly collected and displayed in a Performance Monitor graph. In addition, you can use the typeperf command to get a list of the available counters on the local system.

Membership in the local Administrators group is required to complete these procedures.

View counters in Performance Monitor

To view counters in Performance Monitor:

  1. On the computer where you want to view counters, click Start. In the Start Search text box, type perfmon.exe, and then press ENTER.
  2. In the navigation pane, expand Monitoring Tools, and then click Performance Monitor.
  3. Click the Add button to open a list of available performance counters.
  4. In the Add Counters dialog box, you can click Help for more information on adding counters. When you have finished adding counters to the list, click OK.
  5. Verify that the performance counters you selected are displayed in the Performance Monitor graph.

View a list of counters using the typeperf command

To view a list of counters at the command prompt:

  1. Click Start, click All Programs, and click Accessories. Right-click Command Prompt, and click Run as administrator.
  2. At the command prompt, type typeperf -qx and press ENTER.
  3. Verify that the performance counter list contains expected values.

Using Regedit

After granting the WSS_WPG group full control(you probable can get away with a little less) to the following registry keys, the errors went away. HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesBITSPerformance

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWmiApRplPerformance

Read More

Backup and restore best practices in SharePoint 2013

by Michael Pomfret on 14th June 2016

 

Applies to: SharePoint Server 2013 Standard, SharePoint Server 2013 Enterprise, SharePoint Foundation 2013

 

Summary: Learn how to implement best practices before you back up and restore a SharePoint 2013 farm.

 

Best practices for backup and restore help make sure that backup and restore operations in SharePoint 2013 are successful and that the environment is protected against data loss or continuity gaps.

 

In this article:

 

Performance best practices for SharePoint backup and restore operations

Backup and restore operations consume server resources and limit server performance while the operations are running. Follow these best practices to reduce resource usage and increase the performance of servers and the backup or restore task.

 

Minimize latency between SQL Server and the backup location

In general, it is efficient to back up to a local disk on the database server instead of a network drive. You can then copy the data later to a shared folder on the network. Network drives with 1 millisecond or less latency between them and the database server perform well.

 

Note:
If you cannot back up to local drives, use network drives with similar latency. Because network backups are subject to network errors, verify the backup action after it finishes. For more information, see “Backing Up to a File on a Network Share” in Backup Devices (SQL Server).

 

To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running SQL Server 2008 R2 with Service Pack 1 (SP1) and SQL Server 2012. For more information, seeDefine a Logical Backup Device for a Disk File (SQL Server).

By design, most backup jobs consume all available I/O resources to complete the job. Therefore, you might see disk queuing, which can result in greater than usual latency for I/O requests. This is typical and should not be considered a problem. For more information, see Monitor Disk Usage.

 

Avoid processing conflicts

Do not run backup jobs during times when users need access to the system. Typically, systems run 24 hours a day, seven days a week. A best practice is to always run incremental backups to safeguard against server failure. Consider staggering backups so that all databases are not backed up at the same time.

 

Keep databases small for faster recovery times

Keep databases small to speed both backup and restore. For example, use multiple content databases for a web application instead of one large content database. For more information, seeDatabase types and descriptions (SharePoint 2013).

 

Use incremental backups for large databases

Use incremental backups for large databases because you can make them quickly and maintain performance of the environment. Although you can restore full backups faster than incremental backups, continuous incremental backups minimize data loss. For more information about types of backups, see the following resources:

 

Use compression during backup

In some circumstances, you can use compression to decrease the size of backups and the time to complete each backup. Backup compression was introduced in SQL Server 2008 Enterprise. Backup compression increases CPU usage and this can affect SQL Server concurrent operations.

 

Important:
SharePoint Server 2013 supports SQL Server backup compression. SQL Server data compression is not supported for SharePoint Server 2013 databases.

 

For more information about how backup compression affects performance in SQL Server, see the following resources:

 

Follow SQL Server backup and restore optimization recommendations

SQL Server backups use a combination of full, differential, and transaction log backups (for the full or bulk-logged recovery model) to minimize recovery time. Differential database backups are usually faster to create than full database backups and reduce the number of transaction logs required to recover the database.

 

If you are using the full recovery model, we recommend that you periodically truncate the transaction log files to avoid maintenance issues.

For detailed recommendations about how to optimize SQL Server backup and restore performance, see Optimizing Backup and Restore Performance in SQL Server.

 

Use RAID 10 if you use RAID

Carefully consider whether to use redundant array of independent disks (RAID) on the device to which you back up data. For example, RAID 5 has slow write performance, approximately the same speed as for a single disk. This is because RAID 5 has to maintain parity information. RAID 10 can provide faster backups because it doesn’t need to manage parity. Therefore, it reads and writes data faster. For more information about how to use RAID with backups, see Configure RAID for maximum SQL Server I/O throughput and RAID Levels and SQL Server.

 

Configure SharePoint settings to improve backup or restore performance

You can only configure file compression and log file settings in Windows PowerShell. You can configure backup and restore threads in both the SharePoint Central Administration website and Windows PowerShell to increase backup or restore efficiency and performance.

If you use the Export-SPWeb Windows PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint 2013 uses file compression while exporting web applications, site collection, lists, or document libraries. You can use this parameter to suppress file compression while exporting and importing. File compression can use up to 30% more resources. However, the exported file uses approximately 25% less disk space. If you use the NoFileCompression parameter when you export, you have to also use it when you import the same content.

 

You can also use the NoLogFile parameter. By default, SharePoint 2013 always creates a log file when you export content. Although you can use this parameter to suppress log file creation to save resources, we recommend that you always create logs. Logs are important for troubleshooting and log creation does not use many resources such as CPU or memory.

When you use the Backup-SPFarm cmdlet, you can also use the BackupThreads parameter to specify how many threads SharePoint 2013 will use during the backup process. A higher number of threads will consume more resources during backup. But the overall time to make the backup is decreased. Because each thread is recorded in the log files, the number of threads does affect log file interpretation. By default, three threads are used. The maximum number of available threads is 10.

 

Note:
The backup threads setting is also available through Central Administration on the Default Backup and Restore Settings page in the Backup and Restore section.

 

Consider site collection size when you determine the tools to use

If the business requires site collection backups in addition to farm-level or database-level backups, choose a backup tool that is based on the size of the site collection.

  • Less than 15 gigabytes (GB): Use the Backup-SPSite Windows PowerShell cmdlet. For more information, see Back up site collections in SharePoint 2013.
  • 15-100 GB: Use a SharePoint 2013 tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection. For more information, seeBack up site collections in SharePoint 2013.
  • Larger than 100 GB: Use a differential backup solution, such as SQL Server 2008 R2 with SP1 or System Center 2012 – Data Protection Manager (DPM), instead of the built-in backup and recovery tools.

 

Quality assurance best practices to back up a SharePoint farm

Follow these best practices to help ensure the quality of the backups of the farm environment and reduce the chances of data loss.

 

Ensure you have enough storage space

Be certain that the system has enough disk space to accommodate the backup. Configure a backup job in Central Administration to verify the required disk space.

 

Routinely test backup quality

Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of the backup and to make sure that you can restore the complete environment. To prepare for disaster recovery of geographically dispersed environments, set up a remote farm. Then you can restore the environment by using the database-attach method to upload a copy of the database to the remote farm and redirect users. Periodically perform a trial data recovery action to verify that the process correctly backs up files. A trial restoration can expose hardware problems that do not come up with software verifications and can also to make sure that the recovery time objectives (RTO) are met.

 

Back up ULS trace logs

The SharePoint 2013 backup process doesn’t back up the Unified Logging Service (ULS) trace logs. Data in ULS trace logs can be useful for performance analysis, troubleshooting, and monitoring compliance with service level agreements. Therefore, protect this data as part of the routine maintenance.

By default, SharePoint log files are at C:Program filesCommon FilesMicrosoft SharedWeb Server Extensions15Logs. The files are named with the server name followed by the date and time stamp. The SharePoint trace logs are created at set intervals and when you use the IISRESET command.

 

Store a copy of backup files off-site

To safeguard against loss from a natural disaster that destroys the primary data center, maintain duplicate copies of backups in separate locations from the servers. Duplicate copies can help prevent the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a controlled environment. This should include all backup and recovery materials, documents, database and transaction log backups, and usage and trace log backups.

 

Procedural best practices to back up and restore SharePoint 2013

Use the following procedural best practices to plan and perform backup and restore operations.

 

Use FQDN server names

When you refer to servers in a different domain, always use fully qualified domain names (FQDN).

 

Keep accurate records

When you deploy SharePoint 2013, record the accounts that you create, the computer names, passwords, and setup options. Keep this information in a safe and secure location. Possibly, keep multiple records to make sure this information is always available.

 

Have a recovery environment ready

Use a farm in a secondary location to validate the success of restore operations as part of your disaster recovery strategy. For more information, see Choose a disaster recovery strategy for SharePoint 2013. In a disaster recovery situation, you can then restore the environment by using the database-attach method to upload a copy of the database to the remote farm and redirect users. For more information, review and follow the steps in Restore farms in SharePoint 2013. Also for a high availability solution, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. For more information, see Describing high availability.

 

Schedule backup operations

Use Windows PowerShell backup and recovery cmdlets to create a script file (*.ps1) and then schedule it to run with Windows Task Scheduler. This makes sure that all backup operations are run at the best time when the system is least busy and users are not accessing it. For more information, see the following:

 

Use the SQL FILESTREAM provider with BLOB storage

Remote BLOB Storage (RBS) is supported in a SharePoint 2013 farm. There are both pros and cons associated with using RBS in SharePoint 2013. One related limitation of RBS with a SharePoint farm is that System Center 2012 – Data Protection Manager (DPM) cannot use the FILESTREAM provider to back up or restore RBS. SharePoint 2013 supports the FILESTREAM provider for backup and restore operations. A benefit of RBS with a SharePoint farm is that you can use either SharePoint tools or SQL Server tools to back up and restore the content database with the Remote BLOB Store (RBS) defined. This backs up and restores both the RBS and the content database. We do not recommend that you use RBS with other restore methods. For more information about the benefits and limitations of using RBS, see Deciding to use RBS in SharePoint 2013.

 

Read More
1 2 3