Category: Uncategorized

If you’ve never used AutoSPInstaller (https://www.autospinstaller.com/) to setup SharePoint, I recommend you do so. It takes some of the annoyances out of SharePoint setup – for one, it allows you to name databases as you please instead of letting SharePoint attach GUIDs all over the place. And instead of having to go to multiple places/pages to get everything configured, all your configuration options are in one file.
It’s been awhile since I’ve needed to use AutoSPInstaller, and it’s even better since I’ve used it – instead of editing a XML file in Notepad you can now go through a wizard on their site. Simply copy the files AutoSPInstaller provides along with the SharePoint installer files into the locations it specifies and run the AutoSPInstaller launcher, and soon you’ll have your own little custom SharePoint environment!

Most of the time AutoSPInstaller works great by itself without the need to restart it. In the rare (read: my last attempt) event that it doesn’t and you need to rerun the installation script halfway through, good news – it is definitely possible! Each part of the AutoSPInstaller setup is a function, so we simply have to load the function declarations and your configuration into a SharePoint PowerShell window (as admin):


[xml]$xmlinput = (Get-Content "") -replace "localhost", $env:COMPUTERNAME
. "\AutoSPInstallerFunctions.ps1"


where <path to your XML file> is the path to your configuration file and <path to AutoSPInstaller folder> is where your AutoSPInstaller PowerShell scripts are stored. Notice the space in the second line between the period and the script path.

These commands load the AutoSPInstaller functions into memory and your configuration into a variable named $xmlinput. To continue your installation now all you have to do is open the AutoSPInstallerMain.ps1 file and look at the functions in the order which they are called, then run the functions as desired:

Example:

InstallLanguagePacks $xmlinput
InstallUpdates
ConfigureFarm $xmlinput


h/t to http://spinsiders.com/brianlala/2014/04/30/autospinstaller-for-specific-config-changes/

Got an error from an user who was using Business Data Connectivity to retrieve a large number of records from a database. That generated an error:

“Database Connector has throttled the response. The response from database contains more than ‘2000’ rows. The maximum number of rows that can be read through Database Connector is ‘2000’. The limit can be changed via the ‘Set-SPBusinessDataCatalogThrottleConfig’ cmdlet.”

OK, simple enough. Or, as it turns out, not quite (but definitely still on the easy side!).

1. First, we need the GUID for the Business Data Connectivity service.  Use the Get-SPServiceApplicationProxy cmdlet in the SharePoint PowerShell to do this – just run the command and it will give you a list of service applications and their GUIDs.  Copy the GUID for the BDC.
2. Now we need to get the BDC proxy and assign it to a variable (piping will not work here):

   $ServiceApplication = Get-SPServiceApplicationProxy -Identity <GUID from step 1>

3. If you want to see what the current limits are, you can run the Get-SPBusinessDataCatalogThrottleConfig cmdlet by itself.

   Get-SPBusinessDataCatalogThrottleConfig -Scope Database -ThrottleType Items -ServiceApplicationProxy $ServiceApplication

4. Now set the new limits. This time, we do pipe the results from Get-SPBusinessDataCatalogThrottleConfig to the Set-SPBusinessDataCatalogThrottleConfig cmdlet.

   Get-SPBusinessDataCatalogThrottleConfig -Scope Database -ThrottleType Items - ServiceApplicationProxy $ServiceApplication | Set-SPBusinessDataCatalogTHrottleConfig -Default <new limit> -Maximum <new max size>

5. Repeat step 3 to ensure the changes are applied.

All set!  So really not that bad, just needed to figure out why one would need a variable to be assigned and one needs an unnecessary pipe.

One of our users recently requested that we install one of the SharePoint Application Templates provided by Microsoft. The template the user requested was a Server Admin Template, which meant that the Application Template Core solution had to be installed (see the installation instructions).

The problem was that the solution would never install. It would be stuck in an “Deploying” mode and even though the timer job indicated that it had “Succeeded” it still remained. Attempting to create a new site based on the template would yield an error. Deleting the solutions and reinstalling them didn’t help.

A Google search eventually led to this solution:
http://blumenthalit.net/blog/Lists/Posts/Post.aspx?ID=116

Basically the solution still needs to be deployed to the entire farm; to do this you execute

stsadm -o execadmsvcjobs

on all servers in the server farm. This gets rid of the deployment job and changes the solution status to “Deployed,” after which the template can be used without errors.

We’ve encountered the stuck deployment job when switching service accounts as well, so I’d like to try this when we switch accounts again. Stay tuned.