In the comments you indicate that your SQL Service is running as the Network Service account.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684272(v=vs.85).aspx
The NetworkService account is a predefined local account used by the
service control manager. This account is not recognized by the
security subsystem, so you cannot specify its name in a call to the
LookupAccountName function. It has minimum privileges on the local
computer and acts as the computer on the network.
This is the default account for installations under Vista and Windows Server 2008. During installation this account was granted Full Control file system permissions to the SQL Server data directory as seen in the File System Permissions Granted to SQL Server Per-service SIDs or Local Windows Groups section of the following article.
http://msdn.microsoft.com/en-us/library/ms143504.aspx#Reviewing_ACLs
Since you have relocated some of your database file the SQL Server service account needs permissions to the new locations. In the comments @Marian provided instructions for granting Network Service the required permissions.
Right click the drive -> Properties -> Security -> Edit -> add the
Network Service user -> give him full control. By default he hasn't.
Or better, just create a specific folder and give him Full Control
permissions there. And move the data files in that folder.
The advice to create a new folder and move the files there is excellent as well.
Any additional services that are running as the Network Service account will aslo have permissions to this folder. Ideally the SQL Services should each have their own separate account.
http://support.microsoft.com/kb/2160720
When choosing service accounts, consider the principle of least
privilege. The service account should have exactly the privileges that
it needs to do its job and no more privileges. You also need to
consider account isolation; the service accounts should not only be
different from one another, they should not be used by any other
service on the same server. Do not grant additional permissions to the
SQL Server service account or the service groups. Permissions will be
granted through group membership or granted directly to a service SID,
where a service SID is supported. For more details please refer to
Books Online Topic Setting Up Windows Service Accounts
Okay i resolved the issue!
Repairing the instance didn't help in the first place, as also no instance was found.
The reason was that the Bootstrapper folder wasn't matching the current installation of the SQL Server. The errors of the log files posted above were already pointing in this direction.
Finally i just made a backup of the bootstrapper folder and used
the bootstrapper folder of one of the 2 other machines
where the upgrade did work in the first place.
Now i was able to choose the instance while upgrading and everything worked as expected.
p.s.:
I only tried the Repair-Instance feature while pointing to the installation files of the standard version.
Could this possible be the reason why the instance was not shown?
Best Answer
Well, that error code is:
(source)
This happens when you're trying to install a patch for an application and the patch no longer applies to the application. For example, if the application is version 10 and the patch fixes version 9, the patch will fail with that error.
One possible fix is to uninstall and reinstall SQL Server. Also, you could check to see if you have any patches or fixes installed already. I know that Service Pack 1 is already out for SQL Server. If you have that installed, it could be causing this error (trying to add an old patch to a newer version of PowerShell).