I have been writing in German for a long time at Infrastrukturhelden.de. I was often asked for translations or an English version. After a small test on LinkedIn I decided to translate the page. Since this requires some time and I prefer not to use the Google Translator, please be patient. I will translate as much as possible over time and I will start with the newer articles.
Microsoft goes new ways with Windows Analytics Upgrade Readiness, it is planned to discontinue the service by 31.01.2020. But there is a successor: “Desktop Analytics”. In July the preview for this service was announced, for Germany, this service is still only available in the preview. But there are some pitfalls and disadvantages for some customers, unfortunately.
At the moment these are all just public reflections and preview versions, as time will tell.
In further articles I will explain what you can do with the packaged MSI-X applications
This article, however, is about creating MSIX packages. I will guide you step-by-step.
Here is a list of all the articles in the series and the more detailed articles on specific requirements:
Unattended software installation, also called unattendent installation, is standard in many environments. But how does it work? It is easy with an MSI, but not everything is available as an MSI package. Many applications come with their own methods. Since I also need this from time to time, here is a small collection for the programmes that are more important to me.
Why do I need a name concept?
Let’s start with the example server names. As long as the IT team is small, it doesn’t matter. When external employees join or the team grows, it can help. Here are a few examples of naming concepts that I have already encountered, which may not have been quite so understandable at first glance:
There are many ways to achieve a well-functioning Windows Server Update Services (WSUS) system. Unfortunately, not all of them lead to the final destination, many are rather stages on the way. One of these stages I would like to introduce to you here, solved with some PowerShell.
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).