I have a Raspberry Pi 3 which serves solely as a MySQL server. It does have an important (production-esque) purpose but despite that… I didn’t have it backed up properly. Oops.

So when it spectacularly died the other day, and, um… production things… stopped productioning… I worried a little. Well after I changed my pants, I worried a lot.

Not so much about the server, or even in fact the data, but the structure of the databases.

I recently talked about some simple functionality to chain Powershell commands together so that you can time long-running processes.

I decided to take this concept a little further so that Powershell will send email messages at start and finish so I don’t need to keep checking for when a long-running process has actually finished.

The idea is simple:

• You send a message when it starts
• You run the process
• You send a message when it ends

Note: this assumes you’re in a Windows domain environment with access to an Exchange server. In order to authenticate against Exchange, you obviously need a domain account and be aware, there may be some things about your Exchange environment that does not allow this functionality (e.g., no relaying etc.) If you’re not in an Exchange environment, you’ll need to set the SMTP server of whatever you’re using.

Let’s say, for example, that you’re doing something that takes a freaking age. You need a long-running process and want to fire and forget, but for analysis purposes, want to know how long it took (without sitting there for hours watching and waiting for it to complete.)

The answer is chaining powershell commands together with get-date.

eg.,

get-date;somelongrunningpowershell.ps1;get-date

In this case, it’s the ; that chains commands together.

OK, that was actually a bad example, because if you’re running a script you’re in control of, then obviously you can do whatever you like and output the timestamps then:

I know, I know. SharePoint 2010. Bad. But here I am.

Much of the pain I have been going through over the last week or so is frankly caused by the biggest mistake that a someone designing a new SharePoint environment can make: not planning for data volumes. It doesn’t matter how many times your client tells you “ah, it’ll never grow that big, we won’t use it much” - ignore them, they are lying.

OK, so I’ve posted 5 times in the last 2 days on various SharePoint related things. Any regular readers of this blog will know that is entirely out of the ordinary and does not take a genius to determine that I’ve been doing something with SharePoint and, as with most SharePoint projects, I’ve encountered a bunch of issues. The events that have led to these are probably not common but equally something that you will face from time to time. The perfect storm of requirements consist of:

I recently talked about the method for updating the SharePoint passphrase.

Whilst this did ‘work’ I suffered a slightly unfortunate consequence - which may or may not affect you. (I’m guessing if you’re here, then you’re facing a similar issue.)

As part of what I had been doing, I had changed the Farm Account password. I did this in AD and then manually changed the credentials in IIS and Services.msc for e.g., the Timer service and all other places that I thought it needed changing. However, I did NOT change it in Central Admin for the Managed Account itself.

The content organiser is a powerful feature in SharePoint that allows users to upload files to a single central area and then use rules to route the documents to the correct place.

Creating new rules programmatically is simple but what if you want to change the actual settings of the content organiser? Things like ‘require users to use the organiser’, ‘allow rules to specify another site as a target location’ and so on. This is one area where the SharePoint server APIs fall over a little.

Recently I was trying to figure out a way to restore a copy of a site collection to a different location. (Well that’s the short version, anyway, there was a much bigger issue I was trying to resolve.)

One solution was to backup the site collection and restore it to the new location. The site collection itself is a bit of a monster (around 300gb). From Central Administration I tried to use the GUI screen to backup the site collection to a network share.

Yesterday I posted about a quick hack to reset the farm passphrase. Part of this was using the psconfig cli to perform an in-place upgrade of SharePoint.

Part of this was the command:

psconfig.exe -cmd upgrade -inplace v2v -passphrase "passphrase" -wait

At the time, all seemed to Ok… but today have noticed that the Manage Database Upgrade Status in Central Admin was showing that some databases had been left behind - “Database is in compatibility range and should be upgraded”. And the output from

Was doing a Service Pack upgrade on a SharePoint installation and hit an unexpected error:

Unable to create a Service Connection Point in the current Active Directory domain. Verify that the SharePoint container exists in the current domain and that you have rights to write to it.
Microsoft.SharePoint.SPException: The object LDAP://CN=Microsoft SharePoint Products,CN=System,DC=xxx,DC=com doesn’t exist in the directory.

This seemed odd - I’d just completed the same process on a different environment and didn’t hit the same issue. And after checking with one of the domain admins… confirmed that this container does not exist at all. So it seems it’s a spurious issue.