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.

Install Sysinternals suite in environment path variable to save time

One thing I have been doing for years and saved me lots of troubleshooting time is to install the Sysinternals Suite on every server and put that directory into the path environment variable so you can run any Sysinternals application straight from any CMD or Powershell prompt.
At the time of writing the download link was:
http://download.sysinternals.com/files/SysinternalsSuite.zip

I always uncompress the sysinternals zip file and install them in the same directory (eg c:\sysinternals) for consistency. Once you have installed them add the path of that directory to the Windows path environment variable.

Run this in an elevated Powershell prompt to add your new path to the current path.
[Environment]::SetEnvironmentVariable("Path",$Env:Path + ";C:\sysinternals", "Machine")

Now if you (or anybody else) opens a command prompt or Powershell prompt you can run your favourite Sysinternals commands without navigating to the directory.

Since you always install to the same directory it is easy to update all the servers from a central repository by robocopying a new installation to overwrite the old one. The great thing about Sysinternals tools is that they run without any installation.

It goes without saying that tools of this power so easily run can be a significant security risk so make sure you weigh up the pros and cons in your own environment before 'installing' them.

Openfiles Maintain Objects List global flag behaviour change in Server 2012?

The very useful command openfiles documented below:
http://technet.microsoft.com/en-us/library/cc732490.aspx
Needs the Maintain Objects List global flag set AND A RESTART to track local file handles in Server 2008R2, and is turned off by default to reduce overhead, although I have never seen documented how much overhead it may generate.
However in Server 2012 the command generates a strange message on checking the status.
Server 2008 R2

Server 2012

I suspect the flag is pre-set to ON in Server 2012, and the reason it is on by default is that the new Server 2012 Powershell cmdlet Get-SmbOpenFile requires the same code under the covers and MS wanted it to work straight out of the box. If that is the case it does make you wonder how much overhead is really involved by setting it on… If anyone knows any more about this behaviour please comment.

Powershell makes AD replication status monitoring trivial

Powershell is making monitoring various components much easier than in previous versions of Windows without third party tools.

A great example of this is Active Directory replication. With 15 sites to keep track of I run these commands on a schedule task every 15 mins to create a handy text file on the desktop of the state of AD replication.
repadmin /replsum > replsum.txt
repadmin /showrepl > showrepl.txt

So if there are any issues I can get a quick overview of the summary and detail state of AD replication.

But what I am really interested in knowing is when there is an active directory replication failure for further investigation. This can be achieved and eg emailed in a timely fashion very easily in a few lines of Powershell.
The commands below run repadmin and put the results into an array, then parse the array looking for lines with errors by seeing if the lines are longer in length than lines having no error text. Not pretty but it works well. Note the code -like *dc* which only checks lines with the letters dc contained in them and ignoring any other lines. If all your domain controllers have some other naming convention you would need to change that.


$replsumerror = $false
$arrayreplsum = repadmin /replsum
for($i = 0; $i -le $arrayreplsum.length -1; $i++) {if(($arrayreplsum[$i].length -gt 57) -and ($arrayreplsum[$i] -like "*dc*" )) {$replsumerror = $true}}

if ($replsumerror -eq $true) ...do some event  - eg email


I add this Powershell script on a 15 minute scheduled task and we get easy AD replication monitoring.


I have been disappointed with new Server 2012 Get-ADReplicationFailure cmdlet as it always returns the last error, which could be seconds or years ago. It could do with an option to show only 'current errors'
in a similar fashion to the repadmin /replsum /errorsonly switch or something similar.

Exchange 2010 2 member DAG quorum problem after FSW reboot

Most DAG discussions circle around DAGs with umpteen servers spanning multiple datacentres etc, but I am sure that many DAG’s are much simpler, and are subject to different issues like the one discussed below.
Setup is Exchange 2010 - 2 member DAG with a domain controller (DC) as file share witness (FSW). Whilst the DC was rebooted the DAG would show typical expected error state:


When both Exchange DAG members are online there is no apparent problem and there appears to be nothing amiss, but if you then innocently restart the other DAG member in this state you will hit major problems as the databases on the remaining ACTIVE member will dismount as there is no longer quorum and Active Manager will stop the databases being remounted manually until the other DAG member is back up and everything is back in sync. This behaviour, while logical and ultimately to be expected, is disconcerting to say the least! If you are using one server as a primary and the other as a failover (ie one server has all the active copies of every database) then you have lost all service even though the primary server is 100% up. This scenario could give you more downtime than you might have been led to believe!!!, especially during patching or if you have a design whereby one of the DAG members and the FSW are running as VMs on the same host and the host is rebooted…
But after restart of the DC the cluster still showed an error on file share witness, despite the file share being available.

This was due to the cluster only checking the file share resource once per hour, and I reduced this to 15 minutes. Looking around the internet this article appears to summarise the problem using Exchange 2007 with clusters.
http://blogs.technet.com/b/timmcmic/archive/2009/01/22/exchange-2007-sp1-ccr-windows-2008-clusters-file-share-witness-fsw-failures.aspx
So now the exposure to a loss of quorum was down from 1 hour to 15 minutes after the DC/FSW reboot.
To reduce this further the answer was to manually bring the file share witness resource on line after a reboot. I scripted a ps1 file and put it in scheduled tasks on one of the DAG members to start the cluster resource if was both offline AND the file share witness file share could be accessed, which was the norm after a reboot.
ie IF clusterFSW resource offline AND can access FSW share then try and start cluster resource.

Why the cluster cannot check the FSW resource more frequently is a mystery to me, but I presume there are good reasons.
The motto of the story is to make sure 2 out of the three quorum members are available at all times…