Booting a Microsoft Surface Pro 3 with a broken screen

A few months ago, the Microsoft Surface Pro 3 that I use for work took a knock at one corner and developed a crack across the screen. I was gutted – I’d really looked after the device and, even though it was approaching three years old (and running like a dog), it was likely I’d be using it for a while longer. I could have swapped it for a conventional Dell laptop but I like to use the Surface Pen when I’m consulting. And now it was broken and beyond economic repair (Microsoft are currently quoting £492+VAT for a screen replacement!)

The screen still functioned as a display but the crack was generating false inputs that made both the Surface Firmware and Windows 10 think that I was touching the screen. That was “fighting” with the trackpad or a mouse, meaning that the device was very difficult to control (almost impossible).

I managed to get it up and running and to log on (just about) so that my support team could remote control the device and disable touch for me. The image below shows the two components that needed to be disabled in Device Manager (Surface Pro Touch Controller Firmware and HID-compliant touch screen):

Windows Device Manager, showing disabled devices to work around issues with a broken screen

The biggest problem was booting the device in the first place though – it would load to the Surface splash screen and then stay there. Presumably, the firmware had detected a problem but the hardware hadn’t actually failed, so there was no error message and no successful boot.

Then I found a forum post that gave me the answer:

  1. Hold Power and Volume Up together until the Surface splash screen appears, then let go of the power button.
  2. When presented with the UEFI menu, press ESC to exit.
  3. Press Enter to confirm that you want to quit without saving.
  4. At this point, you’ll see an underscore (_) cursor. Be patient.
  5. After a few seconds, the BitLocker screen will appear, after which the PIN can be entered and the device boots into Windows.

It’s a bit of a faff, but it’s worked for me for the last few weeks. Just before I handed in the broken device (for a replacement with a functioning screen), I recorded this video in my hotel room – it may come in handy for someone…

Weeknote 17: Failed demos, hotel rooms, travel and snippets of exercise (Week 18. 2018)

This week, I’ve learned that:

  • I must trust my better judgement and never allow anyone to push me into demonstrating their products without a properly rehearsed demo and the right equipment…
  • There are people working in offices today who not only claim to be IT illiterate but seem to think that’s acceptable in the modern workplace:
  • That operations teams have a tremendous amount of power to disregard and even override recommendations provided by architects who are paid to provide solid technical advice.
  • That, in 2018, some conference organisers not only think an all-male panel is acceptable but are hostile when given feedback…

I’ve also:

  • Gone on a mini-tour of Southern England working in London, Bristol and Birmingham for the first four days of the week. It did include a bonus ride on a brand new train though and a stint in first class (because it was only £3 more than standard – I’ll happily pay the difference)!
  • Taken a trip down memory lane, revisiting the place where I started my full-time career in 1994 (only to be told by a colleague that he wasn’t even born in 1994):
  • Squeezed in a “run” (actually more like a slow shuffle) as I try to fit exercise around a busy work schedule and living out of a suitcase.
  • Managed to take my youngest son swimming after weeks of trying to make it home in time.
  • Written my first blog post that’s not a “weeknote” in months!
  • Picked up a writing tip to understand the use of the passive voice:

So the week definitely finished better than it started and, as we head into a long weekend, the forecast includes a fair amount of sunshine – hopefully I’ll squeeze in a bike ride or two!

How to stay current with Windows as a Service and Office 365 ProPlus

For many organisations, particularly those at “enterprise” scale, Windows and Office have tended to be updated infrequently, usually as major projects with associated capital expenditure. Meanwhile, operational IT functions that manage “business as usual” often avoid change because that change brings risks around the introduction of new technology that may have consequential effects. This approach is becoming increasingly untenable in a world of regular updates to software sold on a subscription basis.

This post looks at the impact of regularly updating Windows and Office in an organisation and how we need to modify our approach to reflect the world of Windows as a Service and “evergreen” Office 365?

Why do we need to stay current?

A good question. After all, surely if Windows and Office are working as required then there’s no need to change anything, is there? Unfortunately, things aren’t that simple and there are benefits of remaining current for many business stakeholders:

  • For the CIO: improved management, performance, stability and support for the latest hardware.
  • For the CSO: enhanced security against modern threats and zero-day attacks.
  • For end users: access to the latest features and capabilities for better productivity and creativity.

Every Windows release evolves the operating system architecture to better defend against attacks – not just patching! And Windows and Office updates support new ways of working: inking, voice control, improved navigation, etc.

So, updates are good – right?

How often do I need to update?

We’re no longer in a world of 5+5 years (mainstream+extended) support. Microsoft has publicly stated its intention to ship two feature updates to Windows each year (in Spring and Autumn). The latest of these is Windows 10 1803 (also known as Redstone 4), which actually shipped in April. Expect the next one in/around September 2018 (1809). Internally to Microsoft, there are new builds daily; and even publicly there are “Insider” Preview builds for evaluation.

That means that we need to stop thinking about Windows feature updates as projects and start thinking about them as process – i.e. make updating Windows (and Office, and supporting infrastructure) part of the business as usual norm.

OK, but what if I don’t update?

Put simply, if you choose not to stay up-to-date, you’ll build up a problem for later. The point about having predictable releases is that it should help planning

But each release is only supported for 18 months. That means that you need to be thinking about getting users on n-2 releases updated before it gets too close to their end of support. Today, that means:

  • Running 1703, take action to update.
  • Running 1709, plan to update.
  • Running 1803, trailblazer!

We’re no longer looking at major updates every 3-5 years; instead an approach of continuous service improvement is required. This lessens the impact of each change.

So that’s Windows, what about Office?

For those using Office 365 ProPlus (i.e. licensing the latest versions of Office applications through an Office 365 subscription), Windows and Office updates are aligned (not to the day, but to the Spring and Autumn cadence):

So, keep Office updated in line with Windows and you should be in a good place. Build a process that gives confidence and trust to move the two at the same time… the traditional approach of deploying Windows and Office separately often comes down to testing and deployment processes.

What about my deployment tools? Will they support the latest updates?

According to Microsoft, there are more than 100 million devices managed with System Center Configuration Manager (SCCM) and SCCM also needs to be kept up-to-date to support upcoming releases.

SCCM releases are not every 6 months – they should be every 4 months or so – and the intention is to update SCCM to support the next version of Windows/Office ahead of when they become available:

Again, start to prepare as early as possible – and think of this as a process, not a project. Deploy first to a limited set of users, then push more broadly:

Why has Microsoft made us work this way?

The world has changed. With Office existing on multiple platforms and systems under constant threat of attack from those who wish to steal our data (and money) it’s become necessary to move from a major update every 3-5 years to a continuous plan to remain in shape and execute every few months – providing high levels of stability and access to the latest features/functionality.

Across Windows, Office, Azure and System Center Microsoft is continually improving security, reliability and performance whilst integrating cloud services to add functionality and to simplify the process of staying current.

How can I move from managing updates as a project to making it part of the process?

As mentioned previously, adopting Windows as a Service involves a cultural shift from periodic projects to a regular process.

Organisations need to be continually planning and preparing for the next update using Insider Preview to understand the impact of upcoming changes and the potential provided by new features, including any training needs.

Applications, devices and infrastructure can be tested using targeted pilot deployments and then, once the update is generally available and known to work in the environment, a broader deployment can be instigated:

Aim to deploy to users following the model below for each stage:

  • Plan and prepare: 1%.
  • Targeted deployment: 9%.
  • Broad deployment: 90%.

Remember, this is about feature updates, not a new version of Windows. The underlying architecture will evolve over time but Windows as a Service is about smaller, incremental change rather than the big step changes we’ve seen in the past.

But what about testing applications with each new release of Windows?

Of course, applications need to be tested against new releases – and there will be dependencies on support from other vendors too – but it’s important that the flow of releases should not be held up by application testing. If you test every application before updating Windows, it will be difficult to hit the rollout cadence. Instead, proactively assess which applications are used by the majority of users and address these first. Aim to move 80-90% of users to the latest release(s) and reactively address issues with the remaining apps (maybe using a succession of mini-pilots) but don’t stop the process because there are still a few apps to get ready!

You can also use alternative deployment methods (such as virtualised applications or published applications) to work around compatibility issues.

It’s worth noting that most Windows 7-compatible apps will be compatible with Windows 10. The same app development platform (UWP), driver servicing model, etc. are used. Some device drivers may not exist for Windows 10 but most do and availability through Windows Update has improved for drivers and firmware. BIOS support is getting better too.

In addition, there are around a million applications registered in the Ready For Windows database, which can be used for spot-checking ISVs’ Windows 10 support for each application and its prevalence in the wild.

New cloud-enabled capabilities to guide your Windows 10 deployment

Windows Analytics is a cloud-based set of services that collects information from within Windows and provides actionable information to proactively improve your Windows  (and Office) environment.

Using Azure Log Analytics, Windows Analytics can advise on:

  • Readiness (Windows 10 Professional): planning and addressing actions for upgrade from Windows 7 and 8.1 as well as Windows 10 feature updates.
  • Compliance (Windows 10 Professional): for regular (monthly) updates.
  • Device health (Windows 10 Professional and Enterprise): assessing issues across estate (e.g. problematic device drivers).

OK, so I understand why I need to continuously update Windows, but how do I do it?

Microsoft recommends using a system of deployment rings (which might be implemented as groups in SCCM) to roll out to users in the 1% (Insider), 9% (Pilot) and 90% (Broad) deployments mentioned above. This approach allows for a consistent but controllable rollout.

Peer-to-peer download technologies are embedded in Windows that will minimise network usage and recent versions support express updates (only downloading deltas) whilst the impact on users can be minimised through scheduling.

When it comes to tools, there are a few options available:

  • Windows Update is the same service used by consumers to download updates at the rate governed by Microsoft.
  • Windows Update for Business is a version of Windows Update that allows an organisation to control their release schedule and set up deployment rings without any infrastructure.
  • Windows Software Update Services (WSUS) allows feature updates to be deployed when approved, and BranchCache can be used to minimise network impact.
  • Finally, SCCM can work with WSUS and offers Task Sequences, etc. to provide greater control over deployment.

What about the normal “Patch Tuesday” updates?

Twice-annual feature updates don’t replace the need to patch more regularly and Microsoft continues to release cumulative updates each month to resolve security and quality issues.

In effect, we should receive one feature update then five quality updates in each cycle:

Where can I find more information?

The following resources may be useful:

 

The contents of this post are based on a webcast delivered by Bruno Nowak (@BrunoNowak), Director of Product Marketing (Microsoft 365) at Microsoft.