Architecting a Solution - Office Web Apps 2013 and PowerPivot

Overview

There's quite a few changes now that Office Web Apps is a completely seperate software package that has to be loaded on completely seperate servers.  For the most part I found the experience of configuring Office Web Apps to be pretty easy.  Microsoft has great step by step documentation:

Configure SharePoint 2013 to Use Office Web Apps: http://technet.microsoft.com/en-us/library/ff431687.aspx

What they are missing in this setup is if you have PowerPivot installed along with Office Web Apps GallerySnapshot.exe doesn't work unless you suppress .xlsx files from automatically opening in Office Web apps.

This is a relatively simple procedure:

Steps:

1.  Open up the SharePoint 2013 Management Shell

2.  Execute two Actions "New-SPWOPISuppressionSetting –Extension “XLSX” -Action “view”" and "New-SPWOPISuppressionSetting –Extension “XLS” -Action “view”" 

Note I set both XLSX and XLS because I want excel files to be consistently handled the same way by the system, always a best practice.

Details of this command:
http://technet.microsoft.com/en-us/library/jj219443.aspx

Architecting a Solution – Best Practice Web Applications Configuration for Content Deployment

Overview

Since SharePoint 2007, content deployment has been part of SharePoint.  Its not a commonly used feature in most collaboration farms, but its essential for web publishing farms.  Makes the tasks of moving data from Development to Staging to Production an automated process.

As automated processes go, its not bullet proof and the larger and more complex your site gets the more likely you will have to republish the full site to correct errors.   Depending on your infrastructure and the size of the site, this could take a long time and your site is essentially down during the process.  To keep your site up you should configure two Web Applications in production for content publishing: a Primary and a Secondary.  The Secondary should not be accessible on the internet.  Each of these Web Applications will have its own content Database and its own Site Collection.  Follow the steps below if you need to fully republish the website with quick turn around.

Steps

1.  Create a new blank site collection on the Secondary Web Application (to the Secondary Database)

2.  Pause all incremental publishing to the Primary Web Application

3.  Publish the site to the Secondary Web Application

4.  Disconnect the database from the Secondary Web Application

5.  Disconnect the database from the Primary Web Application

6.  Connect the Secondary Database to the Primary Web Application (Now the Switch is complete)

7.  Resume incremental publishing to the Primary Web Application

Remember that the site will only be down while you disconnect and reconnect the databases in step 5 and 6.  I recommend that you run a full crawl from your index server to make sure your indexes are fully up to date.

Diagnosing the Problem - Troubleshooting Search Issues

Overview

When I run into issues searching a particular site, there are a few steps that I go through every time.

Steps:

1. Go to Search Administration check the crawl log you should be able to find the url and from here you will quickly be able to diagnose most access is denied or site is unavailable type of issues.

2. If you can't find the url in the crawl log or the error is not apparent, create a new content source with only the site you are having difficulty with, monitor the results of the full crawl, if necessary turn up logging on the SharePoint.

3. If your SharePoint is heavily customized, check the osssearchresults.aspx page for modification from default. If the page is modified, copy the original back in place to test the search results. If there is not an error the fault is within the customization.

Troubleshooting the Timer Service - Resetting the Timer Service Cache

Overview

Occasionally I run into problems with the SharePoint 2007 timer service and one of the tricks I have in my bag is to reset the timer service cache on the server with the issue.

Steps:

1. Start with the server that is running the Central Administration site (complete all steps then proceed to the next server in the farm and repeat)
2. Stop the Timer service, To do this, follow these steps:

a. Click Start, point to Administrative Tools, and then click Services.
b. Right-click Windows SharePoint Services Timer, and then click Stop.
c. Close the Services console.

3. click Start, click Run, type explorer, and then press ENTER.

4. In Windows Explorer, locate and then double-click the following folder:
Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID

5. Back up the Cache.ini file.

6. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.

Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.

7. Double-click the Cache.ini file.

On the Edit menu, click Select All.
On the Edit menu, click Delete.
Type 1, and then click Save on the File menu.
On the File menu, click Exit.

8. Start the Timer service. To do this, follow these steps:
a. Click Start, point to Administrative Tools, and then click Services.
b. Right-click Windows SharePoint Services Timer, and then click Start.
c. Close the Services console.

Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.

9. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.

10. Click Start, point to Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.

11. Click the Operations tab, and then click Timer job status under Global Configuration.
In the list of timer jobs, verify that the status of the Config Refresh entry is Succeeded.

SharePoint 2010 – Datasheet View not working with Office 2010

 

Overview

The 64bit version of office 2010 leaves us a bit wanting.  For those users that uninstall Office 2007 and install the new 64 bit addition, a host of feature will not work without the addition of the 2007 Office System Driver Data Connectivity components.

Here are the details on what is supported:

http://technet.microsoft.com/en-us/library/cc263526.aspx

“Datasheet view

Requires a 64-bit ActiveX control. Microsoft Office 2010 does not provide a 64-bit version of this control.”

Resolution

Download and install the 2007 Office System Driver: Data Connectivity Components

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7554f536-8c28-4598-9b72-ef94e038c891

SharePoint 2010 – Account security inconsistencies

Overview

I think someone was taking a nap when they worked out the least privileged access for SharePoint 2010.

Here are the permissions for the farm service account.  You will notice that local administrative access is not listed (which is a secure design):

http://technet.microsoft.com/en-us/library/cc678863.aspx

Farm service account

The server farm account is also referred to as the database access account and is used as the application pool identity for Central Administration, and as the process account for the Microsoft SharePoint Foundation 2010 Timer service. The server farm account requires the following permissions:

• It must have domain user account permissions.

Additional permissions are automatically granted to the server farm account on Web servers and application servers that are joined to a server farm.

After you run the SharePoint Configuration Wizard, machine-level permissions include:

• Membership in the WSS_ADMIN_WPG Windows security group for the SharePoint Foundation 2010 Timer service.
• Membership in WSS_RESTRICTED_WPG for the Central Administration and Timer service application pools.
• Membership in WSS_WPG for the Central Administration application pool.

After you run the configuration wizards, SQL Server and database permissions include:

• Dbcreator fixed server role.
• Securityadmin fixed server role.
• db_owner for all SharePoint Server 2010 databases.
• Membership in the WSS_CONTENT_APPLICATION_POOLS role for the SharePoint Server 2010 server farm configuration database.
• Membership in the WSS_CONTENT_APPLICATION_POOLS role for the SharePoint Server 2010 SharePoint_Admin content database.

Permissions necessary to run the Profile Synchronization service:

http://technet.microsoft.com/en-us/library/ee721049.aspx

To create a new Profile Synchronization connection

1. Verify that you have the following administrative credentials:

   • The Server Farm account, which is created during the SharePoint farm setup, must also be a member of the Administrators group on the server where the User Profile Synchronization service is deployed. For more information, see Account permissions and security settings (SharePoint Server 2010).

 

All of this I would forgive as a slight miscommunication if there wasn’t also a rule in the Health Checker which throws up a yellow flag:

 

Because the farm account is also used to host the central administration application pool. 

Possible Solution:

It may be that we should change this service account to a separate account that is both a local administrator on SharePoint servers this could be done through CA:

This would have to be tested pretty thoroughly because the documentation is very specific to use the “Server Farm account” if this doesn’t work, the User Synchronization service should never be placed on the server with Central Administration.  Typically in our 6 server redundant design, that means placing the User Synchronization service on the WFE servers.

SharePoint 2010 – Opening Port in the firewall for the Document Conversion Load Balancer service

Overview

If you receive the error below, your Document Conversions Launcher service cannot reach your Load Balancer service, very likely because you haven’t opened a port in the firewall.  These errors stack up pretty quickly in the application event log, you will probably notice one every few minutes.

Critical Error 7933

"The Office HTML Viewer Service could not be registered with Office HTML Load Balancing Service."

Procedure:

On the server that has the Load Balancing service, go Control Panel –> Windows Firewall –> Advanced Settings

Under Inbound rules create a rule to allow connection to the Load Balancing Service.  Below are the screen shots with the default port: 8093.