When you Add Feature in Visual Studio, it by default creates a ‘folder’ with some gubbins underneath it. By default this is Feature1.

This is pretty ugly, but you may encounter a scenario where you cannot rename it. It seems to be based on other characters that exist in the path of the solution/project. For instance, we tend to use full stops to delineate a pseudo namespace. Now amount of Right-Click > Rename will sort it.

If you want to connect to MySQL from any device in your network that isn’t on localhost, then you may encounter an error:

MySQL error: Could not connect to any of the specified hosts

Bear in mind that e.g., a PHP web app or phpmyadmin will continue to work, since (assuming your web server such as Apache is running on the same server as MySQL) they’re technically running on localhost and will be able to connect.

This is the second part of a guide on recovering MySQL data from a broken Raspberry Pi.

Part 1: Rebuild the Raspberry Pi
Part 2: Recover the MySQL data and restore to the new environment.

With a newly functional Raspberry Pi, it was now time to try and recover MySQL data. Clearly this will only work if the SD card in the old Pi itself is actually functional and readable.

The good news is that MySQL stores its data on the file system in a reasonably compact and accessible format. There are a few differences in structure based on whether your database tables are in MyISAM or InnoDB format. This post assumes your tables are in InnoDB format (since that’s what mine were) but as far as I know, the only difference is that if your tables are in MyISAM format, then there’s no need to copy the ibdata* files over.

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.