10 fixes for Windows 10 updates

How to fix a stuck Windows update

Operating system updates are a necessary evil, like taxes and car MOTs: they can be a real chore, but they’re essential for a happy and peaceful life. You might not care for Windows updates, but they keep you protected, squash nasty bugs and generally keep the OS running as smoothly as possible.

Speaking of running smoothly, however, these updates don’t always do that. In recent versions of Windows Microsoft has tried to make the process as pain-free as possible, but with so many hardware and software configurations out there, there’s always the chance that some unexpected problem will crop up.

But if it does, don’t panic – we’ve got you covered. Read on to learn how to fix common problems with Windows updates.

1. Make sure the updates really are stuck

How to fix a stuck Windows update

We’re going to cover a lot of ground here for several versions of Windows and a variety of ‘stuck’ scenarios, so you may have to tweak some of these steps to suit your situation and software.

The first point to make is that interfering with updates that aren’t actually stuck can cause a host of problems, so you want to make sure they really are stuck.

If you’ve got the time, and the patience, we’d recommend waiting a couple of hours, especially with slower machines – go and cut the grass or watch a movie. It may seem extreme, but you don’t want to start meddling with these fundamental processes unless you really have to.

2. Turn it off and on again

How to fix a stuck Windows update

Do you know why “have you tried turning it off and on again” is such an IT support cliché? Because it so often works. There’s no magic trick to this – it simply clears out your computer’s temporary memory (including any stalled files or processes), and lets Windows start again from scratch with everything on the system.

If your updates are stuck in the background while you still have access to Windows, you can restart as normal; if they’re stuck before or after the OS loads, you’re going to have to hold down the power button and do a hard reset. This can cause issues itself, so make sure your updates definitely aren’t progressing at all.

3. Check the Windows Update utility

How to fix a stuck Windows update

In Windows 10 you can find the Windows Update page by launching the Settings app from the Start menu and clicking Update & Security – if there’s something wrong and Windows knows what it is then you should find details here. Sometimes you’ll just get a message telling you to try the update again at a different time.

If you click ‘Advanced options’ and then ‘View your update history’, you can see recently installed updates that were successful, and uninstall some or all of them – again, this can be a handy troubleshooting option. Windows 10 has actually streamlined the update process, so you should be seeing fewer errors.

4. Run Microsoft’s troubleshooter program

How to fix a stuck Windows update

Microsoft feels your pain: it knows the update process can cause problems every now and again, which is why it’s developed a troubleshooter program specifically for it – search the old Control Panel for “troubleshooting”, then select ‘Fix problems with Windows Update’ from the list on-screen.

The link should be available in Windows 7 and 8 too, but if not you can get at it on the web as well. That said, if you haven’t yet upgraded to Microsoft’s latest and greatest operating system then it’s probably still worth your while, as it’s more than likely to solve your update problems at the same time.

5. Launch Windows in Safe Mode

How to fix a stuck Windows update

Safe Mode is like a restart with extras – only the very basic apps and code that Windows needs to run are loaded into memory, so there’s even less chance of a rogue, damaged file interfering with the update. In Windows 10, hold down the Shift key then choose Power and Restart from the Windows sign-in screen.

On the next screen you see pick Troubleshoot, Advanced Options, Startup Settings and Restart, and you should then see the Safe Mode option appear: try running through the update process again if you can. A quick search online will give you Safe Mode instructions for older versions of Windows.

6. Go back in time with System Restore

How to fix a stuck Windows update

System Restore has been helpful for solving Windows problems for many a year now, but it happens to be quite well hidden in Windows 10. Go to Control Panel, System, System Protection and then click System Restore. Go through the wizard, then choose ‘Show more restore points’ to see all your available options.

Pick a time and date, then complete the wizard to go back to how Windows was configured at that point (and hopefully solve your update issues at the same time). The process doesn’t affect your personal files or programs, but it may not be available to you depending on how Windows was originally set up.

7. Delete the Windows Update file cache yourself, part 1

How to fix a stuck Windows update

If Windows’ own troubleshooter doesn’t work (see step 4) then you can try and carry out the same process yourself manually: stopping the Windows Update service, deleting the temporary files it’s created, then starting Windows Update again. It’s a little more involved, but it’s not difficult to do.

First, boot up into Safe Mode (see step 5), then access to the command prompt, the most basic of Windows interfaces: right-click on the Start menu, choose Command Prompt (Admin), and a text box should appear. Type “net stop wuauserv” and hit Enter, then follow that with “net stop bits” and hit Enter again.

8. Delete the Windows Update file cache yourself, part 2

How to fix a stuck Windows update

Back in Windows proper, navigate to the C:\ Windows\ SoftwareDistribution folder, and delete everything you find therein. You’re not going to break anything by doing this – these are just temporary files Windows creates so it knows where it’s up to, and Windows Update will create them again from scratch.

With that done, go back to your command prompt window and type “net start wuauserv” (Enter) then “net start bits” (Enter) to get Windows Update and its related background services up and running again; hopefully this trick should be enough to kick-start the update that was previously stuck.

9. Launch a thorough virus scan

How to fix a stuck Windows update

One of the more obscure reasons why a Windows update might not be installing is because a virus or some kind of spyware is blocking it: malicious apps like these can often be squashed by Windows security updates, which is why they try and stop the latest patches from being installed on your machine.

Try running a full and thorough virus scan using whatever security software you have installed (you do have some installed, right?). If you think your antivirus tool has also been compromised you can download some on-demand scanners, like this one from Microsoft or this one from Dr. Web.

10. Run a full Windows reset

How to fix a stuck Windows update

Restoring key Windows files and OS options is a lot easier than it used to be, and ‘resetting’ Windows 10 basically means putting all the system files back to their factory state without touching your personal files along the way (although you can choose to wipe your drive completely if you want).

You can find the option via the Recovery tab on the Update & Security page in the Settings app – note that third-party apps are removed too, so these will need installing again. Windows 8 offers both ‘refresh’ and ‘reset’ options, while on Windows 7 the reset option will typically have been provided by the PC’s manufacturer.

You don’t need standup

Notice: Below represents PERSONAL beliefs of palmerj3 (Engineering lead at Spotify) about agile and team organization. Your results may vary.

I recently became a technical product manager at work and this puts me in charge of a team of engineers for the first time. Up until January I was a developer who was upset at how many meetings I had.

So I ran an experiment for the last six months which consisted of a few new behaviors:

  1. No stand-ups
  2. No planning at regular intervals
  3. No retros
  4. All meetings are optional

This may sound extreme. But there is some logic to this madness.

I wanted the team to know I trusted them. To know that it’s ok to tackle tech debt, explore, and work at their own pace. I laid out the goals for the quarter and trusted that the work would get done. Then I got the fuck out of the way.

Would you believe it: work got done. A lot of it.

We were an extremely productive team that responded to change and nailed every goal we set out to.

But before we go into detail about why this experiment worked, let’s see how a typical agile team operates.

A typical agile team

We’re going to create a fictitious team called the SuperAgileRockstars.

SuperAgileRockstars do weekly sprints.

So every Monday they spend an hour planning the work for the week. They meet every morning at 10am for standup where each team member says what they did yesterday, what they are doing today, if tasks are blocked, and give announcements. At the end of the week they spend an hour doing a retrospective where they discuss what went right, what went wrong, and create tasks to address these issues.

It sounds pretty logical, right?

How can this paradise of productivity be broken? Let’s see.

  1. Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
  2. Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
  3. Standup forces every team member to be productive at a set place and a set time
  4. Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
  5. Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
  6. Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?

What would happen if we didn’t plan every week, didn’t do retros, and didn’t do standup?

Stop doing standup

Standup has always bothered me. It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt, and has been known to last longer than 1/2 hour.

The natural side effects of not doing standup are:

  1. Developers communicate more
  2. Your team becomes more remote-friendly
  3. Tech debt gets addressed
  4. Developers feel more in control and less stressed
  5. Developers know you trust them and that you have their back

At Spotify my role is a technical product manager. It’s my role to “steer the ship” (e.g. decide what we work on). If I’m changing my mind about this on a daily basis that’s problematic. If the entire organization changes its mind on a daily basis then it’s my job to fix that.

The reality is: I’ve told my bosses what we’ll deliver by the end of the quarter and I would rather trust that my team know what’s required to get there and be creative along the way.

I want to give them as much freedom as possible to get shit done.

Feel like taking a day off to work on open source? Fuck yeah.

Feel like working on something completely different for a few days? Have fun.

Think our tech debt is out of hand so you want to spend some time fixing it up? We are best friends now.

I know you’re going to get us to our goals and who am I to tell you every single day, “well the highest priority item on the backlog is x,y,z”.

Fuck that noise.

Stop planning every sprint

Planning on a regular basis is another thing that has always bothered me. It’s rare, in my experience, that things change so drastically that the entire team needs to get together and figure things out. But if there is an emergency then by all means call a meeting and communicate that shit. That said, I’m not against planning, I’m against planning on an interval.

So what do things look like if we don’t plan every week or two:

  1. Developers are trusted to be working on the correct things
  2. Developers aren’t interrupted nearly as much so things get done
  3. Backlog is used as a priority queue of work to be done
  4. Tasks are added to the backlog as needed, continuously
  5. Blockers are communicated right away
  6. Planning happens when plans change. Meeting fatigue is reduced and the team knows this was a last resort and is important

Stop doing retros

Say you’re in a relationship and it’s going amazing. You should totally start going to couples therapy once a week, right?

Of course not. So why the fuck are we doing retros every week or every month?

Furthermore, why are we waiting until retros to discuss problems or to give praise?

What do things look like when we stop doing retros:

  1. Developers aren’t interrupted and get shit done
  2. Problems are addressed sooner
  3. Stickies and sharpies are returned and we buy lunch instead

Here’s some questions I know you’re wanting to ask

“How will I know what to work on?”

Good: Pick an item from the backlog.

Better: The backlog is prioritized and you pick the highest priority item from the backlog.

Best: You work on tech debt or open source because you need a mental health day.

“What do I do if I’m blocked?”

Good: Pick a different item from the backlog.

Better: Create a “blocked” column in trello, move the task there, then pick a different item from the backlog.

Best: Put the task in the “blocked” column, pick a different item from the backlog, and drop a message in slack letting the team know it’s blocked.

“How will I track the progress?”

Good: Ask the team. Don’t ask every day.

Better: Keep the backlog up-to-date & relevant. Fucking look at Trello.

Best: Communicate to the team if anything high priority is happening. Otherwise trust that work is getting done until that trust is broken. Casually get updates every so often over lunch and/or beers.

“Hold on. We totally handle tech debt and we do stand-ups!”


You must have vocal developers who are willing to push for tech debt to be addressed and management that deeply cares about engineering quality.

The reality is that most companies don’t operate this way and even your company is likely not a great environment for introverts.


Effective teams question everything. They also trust each other. They also get a lot of shit done.

This article is my attempt to question what’s become the default behavior of agile teams. Daily stand-ups, weekly/bi-weekly planning, and weekly/bi-weekly retros. We didn’t even discuss estimation either.

My advice for all teams is to not start by complicating things.

Stand-ups, planning, and retros are a tool and you should be putting a lot of thought into what tools you use.

Mimecast has Acquired Solebit

Mimecast is excited to announce we have acquired Solebit, a leading security technology provider. A key component of Mimecast’s email solution architecture, Solebit’s differentiated technology has already been protecting our customers with Mimecast’s Targeted Threat Protection globally against the ever-growing, complex threat landscape as a core solution partner.

Realizing the opportunity to change the game for you and your customers with a solution that features a rare combination of stronger protection with higher performance is what led to Mimecast’s decision to make Solebit’s technology ours. We believe the evasion-aware, signature-less, technology has the power to change the game for cybersecurity. The combination of Solebit and Mimecast provides high performance and efficiency combined with tremendous threat protection efficacy—a powerful and rare combination of capabilities.

As with Ataata, the security awareness and training company recently brought into the family of Mimecast solutions in early July, Solebit complements Mimecast’s core cyber resilience platform that includes a messaging solution proven at more than 30,000 organizations globally and a newly emerging Web Security offering that’s currently an Early Adopter program and will be officially launching later this year.

We’re thrilled to have this compelling technology become part of our core technology platform.

For additional detail around Mimecast’s acquisition of Solebit or Ataata, please reach out to your local Partner Account Manager.

Building Serverless Mobile Applications with React Native & AWS

Building Serverless Mobile Applications with React Native & AWS In this post, we’ll look at how to build fully serverless & backendless mobile applications with AWS Amplify & React Native that include features like authentication, analytics, a managed data layer, storage & push notifications. When building a real-world mobile application there are a ton of essential basic requirements. You need to have a way to authenticate users, you want to track user engagement & usage, & you probably want to be able t

Source: Building Serverless Mobile Applications with React Native & AWS

How To Become a DevOps Engineer In Six Months or Less

“Empty highway road in through a colorful desert” by Johannes Plenio on Unsplash

NOTE: This is Part 1 of a multi-part series.

Part 2 is here.

Target Audience

Are you a developer looking to shift your career towards a more DevOps model?

Are you are a classically trained Ops person and you would like to get a feeling of what this whole DevOps thing is all about?

Or are you neither, and simply looking for a career change and have no idea where to start? If so, read on!

Finally, if you have been doing this DevOps thing for years now, you might still find this useful as a validation of where we are and where this is going.

What’s This, Now?

First, what is DevOps?

You can google the definitions and wade through all that buzzword extravaganza but know that most are embarrassingly long word salads stuffed into giant run-on sentences. (See what I did here?)

So, I’ll save you the clicks and distill it down:

DevOps is a way to deliver software with shared pain and responsibility.

That’s it.

OK, but what does that mean?

It means that traditionally, the developers (people who create software) had incentives that were vastly different from operations (people who run software.)

For example, as a developer, I want to create as many new features as fast as possible. After all, this is my job and that’s what customers demand!

However, if I’m an ops person, then I want as few new features as possible because every new feature is a change and change is risky.

As a result of this misalignment of incentives, DevOps was born.

DevOps attempts to fuse development and operations (DevOps, get it?) into one group. The idea is that one group will now share both the pain and the responsibility (and presumably, the rewards) of creating, deploying, and generating revenue from customer-facing software.

Now, purists will tell you know that there is no such thing as a “DevOps Engineer”. “DevOps is a culture, not a role,” they will tell you.

Yeah, yeah. They are technically correct (the worst kind of correct!) but as it so often happens, the term has morphed beyond its original meaning.

Now, being a DevOps Engineer is something like “Systems Engineer 2.0.”

In other words, somebody who understands the Software Development Lifecycle and brings software engineering tools and processes to solve classic operations challenges.

DevOps ultimately means building digital pipelines that take code from a developer’s laptop all the way to revenue generating prod awesomeness!

That’s what it’s all about!

Also note that as a career choice, the whole DevOps space is highly compensated, with almost every company either “doing DevOps” or claiming to do so.

Regardless of where the companies are, the overall DevOps job opportunities are plentiful, offering fun, meaningful employment for years to come.

NOTE: Be wary of companies hiring for a “DevOps team” or a “DevOps department.” Strictly speaking, such things should not exist because ultimately, DevOps is all about the culture and a way of delivering sofware, not a new team or department to be staffed up.


Now, let’s put the glass of Kool-Aid aside for a moment and consider the following.

Have you heard the old adage, “there are no junior DevOps engineers?”

If not, please know it is a popular trope on Reddit and StackOverflow. But what does that mean?

Simply put, it means that it takes many years of experience, combined with a solid understanding of tools, to eventually become a truly effective Senior DevOps practitioner. And sadly, there is no shortcut for experience.

So, this is not an attempt to cheat the system — I don’t think that’s actually possible to pretend to be a Senior DevOps Engineer with a few months of experience. Solid understanding of the rapidly changing tools and methodologies takes years to master and there is no getting around that.

However! There is a roughly agreed upon (trendy, if you will) menu of tools and concepts that most companies use and that is what the article is all about!

Again, tools are different from skills, so while you are learning the tools, make sure you don’t neglect your skills (interviewing, networking, written communication, troubleshooting, etc.)

Most importantly, don’t lose track of what we are after — building a fully automated digital pipeline that takes ideas and turns them into revenue generating pieces of code.

That is the single, most important take-away from this entire article!

Enough Talk, Where Do I Start?

Below is your roadmap.

Master the following and you can safely and honestly call yourself a DevOps Engineer! Or a Cloud Engineer if you detest the “DevOps” title.

The map below represents mine (and probably the majority of folks working in this space) idea of what a competent DevOps Engineer should know. That said, it is only an opinion and there will certainly be dissenting voices. That is OK! We are not after perfection here, we are after a solid foundation upon which to build.

NOTE: You are meant to traverse this breadth-first, layer by layer. Start (and continue!) with the foundation first. Learn the technologies in blue first (Linux|Python|AWS), then if time permits or job market demands, go after the purple stuff (Golang|Google Cloud).

DevOps Foundational Knowledge

Again, go after the first layer in every pillar. Then, time permitting, go after the second layer to add depth to your expertise.

Once you have the Foundation layer reasonably figured out, move onto the real-world set of skills:

Real-world skills

NOTE: What’s notably missing from the pipeline above is Test. That’s intentional — writing unit, integration, and acceptance tests is not easy and traditionally falls on the shoulders of developers. The “Test” phase omission is intentional, since the goal of this roadmap is rapid intake of new skills and tools. Lack of testing expertise is judged by the author to be an insignificant barrier to a proper DevOps employment.

Also, please remember, we are not after learning a whole bunch of unrelated techno-babble here. We are after a solid understanding of tools that taken together, tell a single, coherent story.

That story is end-to-end process automation — a digital pipeline that moves bits around in an assembly line-like fashion.

Moreover, you don’t want to learn a bunch of tools and stop. Tools change rapidly, concepts much less so. Therefore, what you want to do is use the tools as learning proxies for the higher level concepts.

OK, let’s dig in a little deeper!

Foundational Knowledge

Under the top line labeled “Foundation” you will see the skills that every DevOps Engineer must master.

Here, you will see three industry-dominant pillars: operating system, programming language, public cloud. These things are not going to be something that you can learn really quickly, check them off the list and move on. These are going to be skills that you must acquire and keep sharp on a continuous basis, to stay relevant and up to date with what is going on.

Let’s go through them one by one.

Linux: where everything runs. Now, can you be an awesome DevOps practitioner and stay entirely within the Microsoft ecosystem? Of course, you can! There’s no law that mandates Linux for everything.

However! Please know that while all the DevOps-y things can certainly be done with Windows, it is far more painful and the job opportunities are far fewer. For now, you can safely assume that one cannot become a true DevOps professional without knowing Linux. Therefore, Linux is what you must learn and keep learning.

Honestly, the best way to do it is to just install Linux (Fedora or Ubuntu) at home and use that as much as you can. You will break things, you will get stuck and then you will have to fix it all and in the process, you will learn Linux!

For reference, in North America, the Red Hat variants are more prevalent. Therefore, it makes sense to start with Fedora or CentOS. If you are wondering whether you should get the KDE or Gnome edition, get KDE. That’s what Linus Torvalds uses. 🙂

Python: the dominant back-end language these days. Easy to get started with, widely used. Bonus: Python is very prevalent in the AI/Machine Learning space, so if you ever want to transition to yet another hot field, you’ll be all set!

Amazon Web Services: Once again, it is impossible to become a seasoned DevOps professional without a solid understanding of how a public cloud works. And if knowledge of a cloud is what you are after, Amazon Web Services is the dominant player in this space, offering the richest set of tools to work with.

Is it possible to start with Google Cloud or Azure instead? Absolutely! But we are after the biggest bang for the buck here, so AWS is the safest play to make, at least in 2018.

You get a free tier to play with when you sign up for an account at AWS, so that is a good place to start.

Now, when you log into the AWS console, you are greeted with a simple, easy to understand menu of choices.

“Discovering yet another AWS feature I never knew about” by Tom Pumford on Unsplash

That was sarcasm. Good news is, you don’t need to know every single Amazon tech.

Start with the following: VPC, EC2, IAM, S3, CloudWatch, ELB (under the EC2 umbrella), and Security Groups. These things are plenty to get you started and every modern, cloud-enabled enterprise will be using these tools heavily.

AWS’ own training website is a good place to start.

I recommend you set aside 20–30 minutes daily to practice Python, Linux, and AWS.

NOTE: this will be in addition to the other stuff you will have to learn. Altogether, I estimate that spending an hour daily, five times a week is enough to give you a solid understanding of what is going on in the DevOps space within 6 months or less.

That’s it for the Foundational Layer!

In the subsequent articles, we will explore the next level of complexity: how to Configure, Version, Package, Deploy, Run, and Monitor software in a fully automated way!