One of my main envies of Linux in the past years have been Apt-Get – the solution for managing installs and updates of software packages. There have been a couple of different solutions available for Windows historically. The best known one is a third party solution called Chokolatey that you can install and use on Windows and which has a huge repository of software available. The issue I had with Chokolatey was that is was not built-in to Windows… It felt a bit off having to install software to be able to install software.
A couple of years ago Microsoft included OneGet in Microsoft Powershell and I tried is a couple of times but being a bit lazy as I am I always felt it was a bit over-complicated. I never got the hang of having to install an trust providors and repositories. Since I mainly do this once when I reinstall a computer I never really found it worth the time to learn how to do this.
Fast forward to May 2020 when Microsoft introduced Winget. It was first made available as an install from Windows Store or directly from Github and from around May 2021 it is included in Windows as a default with no extra install required.
Yesterday when I reinstalled my computer I thought I would give is a shot.
To find software you use winget search. You can for instance type “winget search microsoft.” (Note the . at the end) to see all Microsoft software in the repository.
When you see the list of Microsoft packages you see that a lot of the regular downloadable packages such as Powershell and OneDrive. You will also find Microsoft Office, Teams and Visual Studio. All of Microsoft’s redistributable packges for supporting .NET and C++ are also available if you have any pre-requirement packages. A lot of the software might require a license which you will have to provide… when you for instance install Office you log into it as usual to provide your license informaton.
To install software you use the command winget install. You could for instance use winget install PowerToys to install Microsoft PowerToys or winget install “Microsoft vscode-insiders” to install Visual Studio Code Insider version. Note that you can use any of the information in the search results to identify which package should be installed.
Winget also handles the update of packages. To upgrade a specific package you can use winget upgrade [package name] or just use winget upgrade to upgrade all packages.
Quite ofter when I look in the eventviewer I can see issues that the Event ID text does tell me anything other than it is not possible to show the message. I got this today at a customers that is running AX so I descided to find the solution. The error message I got looked like this:
I searched around a bit and found a solutin online… turns out we need to create a registry key pointing to the correct file containing the event text. This could be a exe or a dll file.
Below is a link to the information and the entire solution. The short description is this:
Open regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application
Create a new key called Microsoft Dynamics AX
Create a String Value called EventMessageFile and add the following text: C:\Program Files (x86)\Microsoft Dynamics AX\60\\Client\Bin\Ax32.exe
Once in a while it happens that processes and services crashes and when they do you will need a dump. There are some ways to do this using for instance Sysinternals ProcDump, but at some of our customers they have policy do log inactive users of the servers and since ProcDump is running interactively that will not work.
Instead you can use Windows Error Reporting to do this and the good thing… it is builtin to Windows. Here is how you do it:
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps (if the LocalDumps key does not exist, just create it)
Create a new key with name of the process you are trying to debug, in my case Ax32Serv.exe
Under the key you just created you create the settings… in my case DumpCount = 1 DumpType = 2 Which means I want one full dump. The dump will end up in the default directory %LOCALAPPDATA%\CrashDumps (all of these settings are documented in the first link below)
Today when I was recording a Podcast, me and my co-hosts got into a discussion about if it was possible to replace cmd with Powershell in Windows (The reason for the discussion is that the keycombination Win + R, cmd, Enter is ingraved in our spine)… turns out it is 🙂
Todays work consists of implementing a system for managing local admin passwords for Servers and Workstations in an Active Directory Environment. I have used the method in the following (excellent) article series from the PlatformPFE team at Microsoft.
Part 1 – Overview Part 2 – Random Password Generation Part 3 – Secure Active Directory Attribute Update Part 4 – Update Local Account’s Password Part 5 – Logging The Update Process Part 6 – Extending The Active Directory Schema Part 7 – Managing Local Administrators Passwords
In short this series uses a new attribute in AD (set to confidential) to store the local admin password. The password is changed and written to the attribute using a powershell script which is run on every startup of a computer.
There are some aspects of the solution that where not completely obvious to me so I thought I would write the down so I won’t forget them:
The Confidential attribute is a flag that is set on the attribute which requires not only Read Permissions but also CONTROL_ACCESS to the attribute to be able to read it.
There are some limitations:
The confidential flag cannot be applied on most of the default attributes. It is however applied to some default attributes such as Bitlocker Recovery Keys
The CONTROL_ACCESS permission is default set for members of administrators and account operators in active directory which means that these users will always have access to to confidential attributes.
The CONTROL_ACCESS permission can only be set using LDP.exe (which I will explain later how to do). You will need to do this if you want to allow users not member of administrators and account operators to access the local admin password
To set the CONTROL_ACCESS permission for the AD-MemberServers OU-Read-Attribute-LocalAdminPWD group (described in the series), do the following:
Start LDP.exe elevated as a Domain Admin User
Connect to your domain controller
Bind LDP to the domain using your user account
Turn on the tree view in LDP
Browse to the OU where you set up permissions and open Security Descriptor
Double-click the ACL you set to open it and check the Control Access box. Click OK when you are done
Note: If you set up the password solution for Workstations to you will need to repeat the procedure for the workstation OU
To verify if all computers have a local admin password set you can run:
Trots detta vägrade spoolen starta och förbli så. Efter lite letande hittade jag följande lilla guldklimp. När spoolens crashar i Windows hamnar det en log fil i C:\ProgramData\Microsoft\Windows\WER\ReportQueue
Här kan man se exakt vad som strular. I mitt fall var det hptcpmon.dll så jag gick helt enkelt till C:\Windows\system32 och döpte om den till hptcpmon.dll.old och sen startar spoolern igen…