Choosing the right edition of Windows 10 can sometimes be harder than you think for companies. For most companies, the cost versus functionality is a consideration. But which versions are there? More than one actually thinks:
Some questions now, if I was already using the Microsoft Deployment Toolkit (MDT), why should I run Autopilot afterwards? There are several reasons why it can be useful, here are some examples:
I am often asked about the right strategy for “Windows as a Service”. But is there the right way? The short answer is no. It depends as so often on the circumstances, the requirements of the customer and the other customer-specific circumstances. In this article, I would like to point out different ways to the subject of Windows as a Service (WaaS). You will also get tips on what to consider when searching for your way.
What is important is that Windows as a Service is not a project, it is a process. And the challenge is to develop the process for your company in such a way that it works performant but covers all contingencies. This doesn’t just include the question if you want to skip releases.
There are many strategies, approaches and opinions about Windows as a Service. Today I would like to take a closer look at the possibilities. There is the classical and the modern approach, which one can go. But sometimes you still have to use parts of the classical methods.
Let’s take a look at how an operating system migration was carried out in the past. For us, the most important thing is the successful creation of the client build, not the subsequent deployment.
I recently had an interesting phenomenon in a rather extensive environment. With a newly installed WSUS Server based on Windows Server 2016, some clients encountered errors “0x8024400D”. The clients were previously connected to an old WSUS on Windows Server 2008R2. Strange, there everything worked…
The usual attempts to reset the WSUS client, for example, brought no improvement. So I asked Google.
In the past, a company-specific standard was usually always used for local administrator passwords. But what do you do if an employee who knows the default password leaves the company?
Right, it should be changed. In the past, Group Policies (GPO) were often used for this, even if the password was in clear text in SysVol. This was fortunately stopped by Microsoft. What other solutions are available? In practice I have seen VBS or PowerShell scripts, the good ones have random passwords, the bad ones only a standard.
But isn’t there a well designed solution from Microsoft? Yes, there is, Local Administrator Password Solution (LAPS).