SharePoint 2010 – ‘database requires upgrade or not supported’ error post SP1 install

I was unable to search for anything in my SharePoint portal. On inspection in the Central Administration panel, I got the error message in the title.

To correct this, I did as it said in the ‘remedy’ area, when clicking on the problem. In summary:

1) Fired up the PowerShell; in my case with Win 2008 R2 and SharePoint 2010 installed, this can be found as ‘Windows PowerShell Modules’ under the  ‘Administrative Tools’ section on the from the start menu.

2) Run Upgrade-SPContentDatabase -id WSS_Content. If you want to upgrade a different database, you will need to find its GUID instead, which should be listed within the database name

3) You will be asked for confirmation as to whether you want to do this. Upon approving this, a percentage readout will trickle along PowerShell window. This may take a few minutes or more to complete, depending on how much data you have.

4) Your database for content should now be updated!

N.B. Having done the above, I found that SharePoint was still having problems with a lot of other database. My conclusion was that during the SP1 update, it did not update the databases. An easy resolution to this to go to:

Start -> All Programs -> Microsoft SharePoint 2010 Products ->SharePoint 2010 Products Configuration Wizard

This will save a lot of time! The wizard is automated, and fixed all problems for me :) Why the upgrade didn’t do this automatically is anyone’s guess!

RemoteApp programs ‘lock’ after 10 minutes of inactivity

if the user was to leave their computer for 10 minutes, when they returned the RemoteApp was locked. It required re-entering the password for the TS account in use for these apps, something which they shouldn’t even have to know (and don’t)

I’ve just rolled out a 32-bit Windows 2008 Server, for the sole purpose of running our legacy DOS and other 16-bit applications via a Terminal Server (these apps are just a little long in the tooth, but still currently important part to the firm I work for). We’re running Windows 7 x64, so DOS mode is now a non-entity for us on local systems.

For the problem I suffered, this was beside the point. After some effort, the RemoteApps would work absolutely fine, but if the user was to leave their computer for 10 minutes, when they returned the RemoteApp was locked. It required re-entering the password for the TS account in use for these apps, something which they shouldn’t even have to know (and don’t).

With Google as my friend, I set out trying to find a resolution. The resolution was along the lines I thought it might be – it’s all to do with a screensaver ‘time-out’ (the time marker for displaying the screensaver), which kicks in regardless of whether a screen saver is set or not. There were a series of solutions, most suitably involving Group Policy, but I simply couldn’t get them to work.

The problem is, the articles out there tell you what to do, but don’t clarify that the policy needs to ultimately apply to the Terminal Server, or the user account in use with Terminal Server. By implication I was left believing that the policy should be applied to the user workstation itself, and that the 10 minute screen saver setting for the workstation was causing a lock to the remoteapps. This is not the case.

Having established this, I set about creating a GPO. In my case, the setup is simple versus other real world scenarios; I only need one user account that all my RemoteApps are run through, and I only have one 2008 Terminal Server. I have done everything on the terminal server to ensure my user account can access the server via RDP, whether via a RemoteApp or full Remote Desktop Connection.

Because my setup is basic, I was able to put both the TS user account and the Terminal Server in its own OU called ‘Terminal Servers’. From here, I created and linked a GPO, and set the following policy setting:

User Configuration -> Policies -> Administrative Template -> Control Panel / Personalization -> Screen saver timeout

I enabled this setting, and set the value to 0 seconds.

If you have a more complex setup, with Terminal Servers in different OUs to user accounts (highly likely), you may need to play around with loop back processing to get this to work. Also, the templates for GPOs in my Active Directory are based around 2008 R2, so you may find the ‘Screen saver timeout’ setting in a slight different place.

To expidite the application of the new setting, run gpupdate /force from a TS user session on the Terminal Server. Otherwise, wait a time and it should kick it (although a restart to the server might be a good idea, to refresh any disconnected but still open TS sessions).

Internet Explorer prints & previews blank pages (IE7, IE8, IE9)

When trying to print from Internet Explorer (or print preview), all you see is blank content, and some header and footer information. The footer reads something to the effect of:

“file:///C:/Users/userprofile/AppData/Local/Temp/Low/randomfile.htm”

This problem drove me nuts for some time. I first noticed it under Windows Vista with IE8, but from reading out there on the web, it potentially effects any windows system running IE7 onwards (so XP through to 7).

Specifically, I am rolling out Windows 7 at my firm, with IE9 bundled in as part of an Image file. In my case the problem was probably occuring after I installed IE9 using the admin account on the system that the master image was based on (we don’t want users to be able to install their own apps). If I log in to Windows with the admin account directly, all prints fine.

Anyway, enough rambling, you are here because you want to know how to fix it.

Firstly, the ‘Low’ folder mentioned above is needed as a temporary working folder for the HTML pages being generated and printed from IE. Start by bringing up a command prompt (run -> cmd), making sure you DO NOT run with elevated permissions (otherwise it will do this for your local admin account, which won’t help you). At the command prompt, run the following command:

mkdir %userprofile%\AppData\Local\Temp\Low

This will create the necessary Low folder in the right place, which is almost certainly absent otherwise.

Other posts I read suggested this was enough, but it isn’t. The newly created ‘Low’ folder won’t work until you run a further command which sets the integrity level of this folder such that IE can use it (IE7 introduced a new protected mode, which you can read more about here: http://msdn.microsoft.com/en-us/library/bb250462%28VS.85%29.aspx). So at the same prompt, run the following command:

icacls %userprofile%\AppData\Local\Temp\Low /setintegritylevel low

Having done this, restart IE, and you should find print preview and printing itself now works :) Now I just need to correct the 10 systems I already have setup with this little menace of a problem……

Good luck! :)

Removing Exchange 2007 (post Exchange 2010 migration) – Offline Address Book Error

I have now done two separate migrations to Exchange 2010, and in each instance I hit a snag at the final stage – removing the now redundant / last Exchange 2007 server that remains as part of the MS Exchange setup.

Please note, before following the below, make sure you have completed all steps of migration before attempting this process. You must make sure all your mailboxes, public folders, Send Connectors, etc, etc, are migrated, and that you truly are just stuck with an empty vessel of an Exchange 2007 that refuses to uninstall. This is not a short-cut for all the proper processes to follow!

The issue I found, after completing all official removal steps, was that Exchange 2007 would not uninstall stating:

“Uninstall cannot continue. Database ‘Public Folder Database’: The public folder database “MAIL\Second Storage Group\Public Folder Database” contains the following offline address book(s): \Default Offline Address List. Before deleting the public folder database, move the offline address book(s) to a web-based distribution point.”

Needless to say, I have already moved the offline address book in every context to my new Exchange 2010 server. Replication has taken place, and I can see all is well.

So why is this happenning? I suspect (like me) you are asking the same question, and hence you are on this blog.

The answer is that the uninstaller finds an entry in Active Directory that still indicates your Exchange 2007 server is a valid and primary holder for a copy of the public folder, and so fails to remove Exchange 2007. The solution is therefore simple – we remove this errant entry in Active Directory using ADSIEdit.

Here are the steps to follow:

1) You probably don’t have ADSIEdit registered by default, so bring up a command line with admin elevation, and type:

regsvr32 adsiedit.dll

A info box should confirm registration of this mmc snap-in.

2) Bring up the run box and type mmc and press enter.

3) In the MMC console that appears,  go to File and then Add / Remove Snap In…

4) Select the ADSI Edit option from the available snap-ins list, and use the Add> button to add it to the right column. Then click OK.

5) With the ADSI Edit option now available in the MMC console, right click on it and select Connect To… from the properties list that appears.

6) In the Connection Settings properties box that appears, change the option for Select a well known Naming Context to ‘Configuration’, make sure your old Exchange 2007 server name is listed in the ‘Path’ field above this, and then click ok.

7) This should load up a tree structure, with your Exchange 2007 server shown in its internal Fully Qualified Domain Name at the top of the tree (e.g. Configuration [mail2007.mydomain.local].

8) Here’s the disclaimer – editing Active Directory incorrectly can render your domain unusable if done incorrectly, and must be done with extreme caution. I accept no liability for my advice – you have been warned!!!

9) Follow the directory tree as follows, right from the top (I have simplified this, instead of putting every AD naming context in) till you are in the folder at the bottom of this list:

Configuration [servername]->
Configuration ->
Services ->
Microsoft Exchange ->
Your Organisational Name->
Administrative Groups->
Exchange Administrative Group->
Servers->
Exchange 2007 Server Name->
InformationStore->
Second Storage Group->

In that final Second Storage Group branch, you will find a sub-entry called Public Folder Database. Right click this entry, and delete it.

10) Now re-run your uninstall of Exchange 2007, and you should find the error message is gone, and providing you have done everything else to move correctly to another Exchange server, the setup will uninstall your copy of Exchange 2007 :)

Upgrading ESXi 4.0 to ESXi 4.1 via the VMware CLI (Command Line Interface)

Today I had cause to upgrade my firm’s ESXi server from version 4.0 to 4.1. Unless you are lucky enough to own a license of VMware vCentre (and use the update mechanism in this, which I confess I’ve never even looked at) your best option to run the update is from the command line, via VMware’s CLI. Once you get going with this, it really is quite a nice method.

This guide is based on using the free CLI from VMware, running on Windows 7 x64, alongside the vSphere client (version 4.0, from the start off). Please note this is an upgrade guide only, and I won’t be going in to installing ESXi from scratch in this article.

Start by safely shutting down all running virtual machines on your live ESXi server.

Load up the vSphere client (version 4.0) and put the ESXi server into maintenance mode.

Visit www.vmware.com to download the Zip file update of ESXi 4.1. If you haven’t already, you will need to create a free account with VMware, in order to obtain access to all ESXi 4.1 and older downloads (as well as your free license code). Look on the site for the free download of “VMware vSphere Hypervisor”. Note that VMware have decided to change the name in some documentation and site pages to this, but for the sake of this blog I will refer to the new release still as ESXi 4.1. The file you need to download is listed as “ESXi 4.1 (upgrade ZIP from ESXi 4.0)”. I recommend you save this update directly to the C: drive root on your computer, as I have done for this tutorial.

If you don’t already have it, download and install the VMware vSphere CLI (Command Line Interface) from http://communities.vmware.com/community/vmtn/vsphere/automationtools/vsphere_cli and install on your local Windows client. This installer includes ActivePerl – an environment needed for CLI to work.

From your Windows client load up the Windows command line (cmd), ensuring you have full admin rights applied if running Vista or later. Type one of the following from the command prompt in order to get in to the CLI script folder:

For 32-bit OS:
cd C:\Program Files\VMware\VMware vSphere CLI\bin

For 64-bit OS:
cd C:\Program Files (x86)\VMware\VMware vSphere CLI\bin

To list all patches already applied to your ESXi install, type in the following command:

vihostupdate.pl –query server 192.168.1.17 username root password PASSWORD

This will list all patches and updates already installed on your ESXi server (since the last major update), as below. (In the above command, substitute the server IP address to your own ESXi server’s IP, and PASSWORD to be your case sensitive root access password you use).

To analyse the contents of the zip file update you’ve downloaded VMware, and compare it to the patches already installed on your ESXi 4 server, run the following command (same substitution rules apply):

vihostupdate.pl –server 192.168.1.17 –username root –password PASSWORD –scan –bundle c:\upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip

This will produce an output, somewhat similar to the below. Note, this will list all patches within the update that your ESXi server doesn’t already have installed.

This output tells us that the bundle contains the two patches that upgrade us from 4.0 to 4.1, and that these aren’t currently evident as part of your existing install.

Now you’re ready to run your update. Needless to say, by the time you’ve got this far make sure you have backed up all your virtual machines (and their contained data), and your current ESXi install. Things can go wrong, and you must always have a fall back plan. You’ve been warned!

So from here, run the command below (with substitutions as before) to start the update…

vihostupdate.pl –server 192.168.1.17 –username root –password PASSWORD –install –bundle c:\upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip

A message should be returned and read:

“Please wait patch installation is in progress …”

Be patient. It can take quite a few minutes for the install to complete. Once it does a message should read:

“The update completed successfully, but the system needs to be rebooted for the changes to be effective.”

If you haven’t already, fire up your vSphere client and reboot ESXi from the GUI.

Post a reboot of ESXi, attempt to re-logon from the vSphere client, and you will be prompted to update your vSphere client. Either run the installer, or download and install the client update manually – you won’t be able to access ESXi till you do.

Back to the command line, run the following query command again to verify updates:

vihostupdate.pl –query –server 192.168.1.17 –username root –password PASSWORD

A result should be returned as follows:

This shows the update has applied successfully, and you are running ESXi 4.1. You can also check build versions from the ‘About’ menu option in the vSphere client software.

Finally, take your newly upgraded ESXi 4.1 server out of maintenance mode in the vSphere client, and start all your live virtual machines. Upgrade Vmtools in each VM (with reboots), then you’re done!