Windows 8 users confused over desktop / start menu

In the past few weeks I have helped users with new Windows 8 laptop. In every case they had used used Windows before and were very confused where the start menu had ‘gone to’. In one case they were accused of ‘doing something’ to the laptop when they showed it to a relative as the relative thought they had broken Windows. The more I see Windows 8 the decision to remove the traditional start menu is just wrong on non touch devices. The uncomfortable jump between the desktop and the new touch oriented start menu does not feel correct. Why the old start menu was removed for Windows 8 RTM is still a mystery for me. The whole thing could be fixed so easily with a few lines of code that presumably and deliberately was never written by MS.
If touch screen then go to new start menu
Otherwise
Go to desktop and add Windows 7 Start Menu
Then allow more experienced users to select either of the above as default behaviour. The default behaviour may need to change if the user uses lots of Windows 8 Apps instead of traditional Apps.
The final icing on the cake was I asked a Windows user of 10 years+ to turn the laptop off, and they couldn't work out how to do it. I showed them that the charms bar, ALT F4 and CTRL-ALT-DEL could be used, but they were still amazed at the lack of usability. So here is a vote to do something about it. On my own laptop I have settled on the Classic Start Menu, whilst on my development Server running Server 2012 I have left the original behaviour to always remind myself how it works out of the box. It is not all bad as pressing the start key and typing the program you want to run still works the same, although I don’t see any advantage over Windows 7 Start Menu. If you use the Surface Touch Screen the new system works well, except non touch devices will be in the majority for some time to come. So here is a vote to change the behaviour of Windows 8 start menu on non touch devices. In a couple of years it will be less of a problem as touch screen devices will be ubiquitous. MS no doubt has already decided against this plan, although if business take up of Windows 8 is low they may be forced to rethink...

Restore of physical Dell Server 2008R2 with Perc H700 to VM fails with stop 7b inaccessible boot device

I have come across this several times in the last year and decided to document the answer myself so I can find it more quickly next time! The best answer is to be found here if you want full details:
http://www.minasi.com/forum/topic.asp?TOPIC_ID=31980

The scenario is:
Take a windows backup of a Dell (and probably other manufacturers) Server 2008R2 with a PERC (or equivalent) disk controller:

eg wbadmin start backup -backuptarget:\\remoteserver\remoteshare -include:c:,d:,e:  -allcritical -vssfull

This creates a VHD(s).

Then go to Hyper-V and restore this backup to a new VM.

Lo and behold when you boot the VM you will get a stop 7b - inaccesible boot device.

Then mess around looking for the answer for half an hour.

The answer is simple.
Mount the VHD
Load the registry of your newly restored server.
Go to:
 HKLM\System\ControlSet001\Services\Intelide and change Start to 0
 HKLM\System\ControlSet001\Services\Pciide and change Start to 3

Restart - it boots perfectly. Why the bare metal restore cannot sort out the above automatically I just cannot fathom. This type of problem has been going on for ages and plagued moving XP/2003 disks to different hardware. The bizarre thing is that on NT4 you could manually 'preload' another driver (I admit the number of drivers was very limited!) and move to different hardware more simply - so much for plug and play! I should point out that using disk2vhd always works perfectly in the above scenario so it must have code to workaround the problem, although it does have the advantage of guaranteeing the hardware that will be presented to to the VM!

I have not tried to see if it is 'fixed' on Server 2012, but it probably isn't.

Beware SQL Developer/Enterprise feature add column on Standard edition

I always add new columns to SQL Server 2012 on large tables out of hours due to the extended table locks required. Factor in merge replication which I use heavily and is usually impossible to recover from schema failure (mitigated potentially by sp_markpendingschemachange) and I usually take a full backup of publisher and all subscribers (which are fixed servers, not mobile clients making it simple) before making schema changes.

A developer said they didn't understand the problem as schema changes on their 'dev' database only took a second. I had to explain that the Production database was on SQL Server 2012 Standard Edition and they were using SQL Server 2012 Developer Edition, and that Developer Edition is the same as Enterprise Edition, including the feature that allows Enterprise Edition to add columns almost instantly for most standard schema changes. here is an extract from SQL Server 2012 BOL.


Adding NOT NULL Columns as an Online Operation

In SQL Server 2012 Enterprise Edition, adding a NOT NULL column with a default value is an online operation when the default value is a runtime constant. This means that the operation is completed almost instantaneously regardless of the number of rows in the table.

A standard new column line syntax for a merge replicated table might be:
alter table mytable add mycolumn int constraint de_myconstraint default 0 not null
where the new column is defined in 1 DDL operation.

This could easily catch out unwitting users who try out a schema change on their 'dev' database, finds it completes subsecond and then try the same on Standard Edition and wait around for a potentially long time waiting for the schema locks to be dropped.
This Developer Edition vs Standard Edition problem has continued to get worse over the years and the feature difference is now very large.
If only MS would put a trace flag or other feature to allow Developer edition to behave as Standard Edition or other editions things would be much simpler all round.