SharePoint Experts, Information Architects, Expert Witness

SICG provides a broad array of business and technology consulting from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. We focus on the "How", not just the possible. Contact me direct: or call 704-873-8846 x704.

Search This Blog

Saturday, August 11, 2012

Fun with SharePoint 2013 Installation Issues

SharePoint 2013 Setup

As many of you that have installed SharePoint 2010, there were a few 'gotchas'. Everything from the TaxonomyPicker.ascx file to the oddities in dealing with the User Profile Synchronization Service.

Well, expect no less with SharePoint 2013 (at least in the Preview). Some of the old problems still exist (most of these I've already commented on in this blog - the same 2010 fixes apply to 2013 as well).

Some of the common (found so far) include:

1) User profile still has issues, FIM service got hung up (set to Disabled) and User Profile Sync service 'Stuck on starting'. Waiting for a good 15-20 minutes didn't matter but an eventual reboot fixed the problem. However, there's a new wrinkle in the setup: 2013 User Profile Service requires a separate account for accessing AD and NOT the Farm account. Instead of setting up the Farm Account with rights in AD, it is better to setup an AD Domain Administrator account and use that instead (and be sure to set that account correctly in Central Administration and in the User Profile Synchronization setup).

2) "Missing Server Side Dependencies" - yes this one still exists too; so far, there appears no permanent fix for this except for the same one used for 2010.

3) Setting service accounts still requires hoping back and forth between the landing and setting pages; there are still some pages (like the User Profile Synchronization page) where it leaves you with no where to go but back to Central Administration.

4) Setting the new Distributed cache service account has to be done using PowerShell.

I'll be updating as needed....happy setup!

Thursday, August 9, 2012

The Painful Truth about PowerShell and SharePoint

The Painful Truth about PowerShell and SharePoint

Yes, you’ve heard all about PowerShell and how it makes working with SharePoint so much easier than the old ‘stsadm’ command line. Sure, you can so some slick things – access the object model, create sites, etc. In fact, it's pretty much a must have for working at the farm level. 

Indirectly, you may wonder why PowerShell (in SharePoint) is being pushed so much and there are really two reasons. First, it’s costly to build user interfaces for all of the potential commands available through the API. Exposing them through the command line is much easier – although, you have to like to type. Secondly, it was a way to help bridge the gap for those Linux and Unix users who can never seem to break the habit of a command line interface.

But for all of the effort to learn it – will you actually be able to use it? For most of us, the sad answer is NO – only the Admin’s will. In a typical production environment, it is rare if not out of the question in allowing developers or other non-administrators any kind of command line access. This goes for Office 365 too. So even if have the best scripts in the world, it will be up to the farm admin to allow them to be used.

I offer this as a word to the wise - in providing instruction and courseware, I’ve begun to downplay a lot of the PowerShell training (for SharePoint anyway). If you’re not going to be an administrator, save your precious learning time – learn a little PowerShell to help you in development but concentrate on solutions instead – your time will be better spent with sandboxed solutions, MVC, jQuery, Javascript and HTML5.

Occasional failures in connection in a SharePoint Farm

Having seen this a few times, I figured I'd post this - the problem? Occasionally a SharePoint farm front-end server (or services server) logs failures on database connections such as "Cannot connect to the server xxx".

Most recently, a client had this occur for the oddest reason - it seems that one of the Front-end servers had run out of space and after a short time, completely locked out one of the sites. Cleanup and reboot did not fix the problem - the solution ended up doing a DNS Flush - after that, it appeared to clear the problem.

That said, I've seen other cases where this has happened due to flaky DNS, load balancers, etc.

So a quick fix is to 1) Follow the same rules as we use for Kerberos authentication using the SetSPN command (Service Principal Name). For an overview on this, see here:

For specific detail on the command and syntax, see here:

Another quick fix is to use the Hosts file found on each of the servers (c:\windows\system32\drivers\etc folder). Edit this file with Notepad and simply add all of the servers and IP addresses to the end of the file. For example, for domain   wfe1   wfe2


The downside to this of course, is that any changes mean manual changes on all servers.

Tuesday, August 7, 2012

SharePoint and SQL Server Databases and Log Sizes

Seems SharePoint 2010 (and 2013) seem to over allocate database space and/or logs...

1) Sooner or later you will come across a message in the Central Administration site that will tell you one or more databases have a lot of unused space. Sometimes there is a 'Repair Automatically' button enabled, sometimes not.

2) You begin to notice that the some of the database log files are something like 9 times the size of the database.

Both of these issues can be the same or different problems - in either case, you need to shrink them otherwise performance suffers.

The quick and dirty way to shrink a database is to use the DBCC ShrinkDatabase or DBCC ShrinkFile methods (via a query window, DBCC ShrinkDatabase(<dbname>)).

For the Microsoft outline, see here:

One of the reasons for the size can be either that the database is in Debug mode (thus logging everything) - seemingly the default setting for many and another is that the database log file itself is over allocated (another SharePoint default setting). Using SQL Management Studio, expand the databases, right click on the database name in question and select Properties.

One of the common issues is that the SQL Recovery Model is set to Full - this means full backup recovery. When in this mode, you cannot change the File Sizes - this has to be changed to Simple, the file shrunk then put back to Full if desired.

To view or change the recovery model

1. After connecting to the appropriate instance of the SQL Server Database Engine, in Object Explorer, click the server name to expand the server tree.

2. Expand Databases, and, depending on the database, either select a user database or expand System Databases and select a system database.

3. Right-click the database, and then click Properties, which opens the Database Properties dialog box.

4. In the Select a page pane, click Options.

5. The current recovery model is displayed in the Recovery model list box.

6. Optionally, to change the recovery model select a different model list. The choices are Full, Bulk-logged, or Simple.

7. Click OK.

Use the SQL window to run the DBCC ShrinkFile(<logfile>) command to shrink the file

Right click on the database name, select Files (on the left) and set the default size to be slightly larger than the database

Change the Recovery mode back to Full or leave it as Simple.

NOTE: The risk of using Simple mode is that you will not have debugging information for SQL - however, from a practical point of view, if you have regular backups it is VERY unlikely that Debug information would be of any use in a SharePoint environment.

Just in case you need more help - see the following:

Method 1:

Method 2:

Method 3:

Thursday, August 2, 2012

VMWare Virtuals Lock up for no reason

Another tip for VMWare users - you might notice that on some Windows 2008 R2 installations, that sometimes the system(s) will lock up forcing you to forcibly shut down the box or try logging in using the VMWare Console. If you can log in, it will eventually lock up again.

It seems that the culprit is the SVGA Driver from the VMWare Tools - it seems to have some kind of a conflict with the internal drivers and every now and again causes the lock up. The fix is simple:

Log in and immediately uninstall the VMWare Tools (Start > Control Panels > Uninstall a Program - or Programs and Features). This will cause a reboot.

When the reboot completes, log back in and then install the VMWare Tools again - this time, select Custom install and disable the SVGA driver from installing. Continue the install as usual and you will again reboot.

On restart, log in again - you may see the generic SVGA driver installation message.

Done - problem solved.

VMWare Virtual Machine takes a long time to shutdown

Not sure if I posted this already but while setting up my VMWare Virtuals today (to test out SharePoint 2013!) I noticed the VM was taking a very long time to shut down.

Having dealt with this before, I scrambled around to find the solution and having found it, post it here for you:

VM Takes Long Time to Shutdown Fix
0) Shut down the VM before you do anything; if something like a Production server, you should either backup the entire directory that holds the VM files or take a snapshot (depends on your product).

1) In the VM's folder, locate the <vmname>.VMX file

2) Make a copy (backup) of the file (this is important!)

3) Edit the file using notepad (don't use anything like Word) - locate the following entries in file - if you DO NOT find them, add them to the bottom of the file:

prefvmx.minVmMemPct = "100"
mainMem.useNamedFile = "FALSE"
mainMem.partialLazySave = "FALSE"
mainMem.partialLazyRestore = "FALSE"

4) Save the file and exit notepad

5) Start the VM - let it completely start, log in, then choose normal shutdown - should now shutdown in a matter of seconds.

I've had no adverse effects with these settings but use at your own risk.