.Net Webapi – Unable to start Kestrel

While taking some Azure certifications, I have several times experienced this error during some Labs.

After creating a new webapi with

dotnet new webapi --output . --name SimpleApi

the ensuing

dotnet run

always fails with this error on my Windows 10 development pc.

info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
User profile is available. Using ‘C:\Users\XXXX\AppData\Local\ASP.NET\DataProtection-Keys’ as key repository and Windows DPAPI to encrypt keys at rest.
crit: Microsoft.AspNetCore.Server.Kestrel[0]
Unable to start Kestrel.
System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
To generate a developer certificate run ‘dotnet dev-certs https’. To trust the certificate (Windows and macOS only) run ‘dotnet dev-certs https –trust’.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

The instructions on this page does not initially help much. As other people also experience, one dotnet dev-certs command says no valid certificates exist while another says that one already exists.
What have worked for me until now, is to first clear my pc of all existing dev certificates and then generate a new one. I seem to have to do this everytime i create a new project…

dotnet dev-certs https –clean
dotnet dev-certs https –trust

I always comment out the app.UseHttpsRedirection(); in the autogenerated Startup.cs class, but it does not make any difference.

MSDN installation files

I just learned, that MSDN installation files (at least for Windows) are not full installation files, but (apparantly) crippled ones.

If for instance, you need a Windows 10 installation media, you should not normally use the one from MSDN, but download it from microsoft.com instead.

My specific problem, was that the package from MSDN would not accept the product-key which was embedded in BIOS, whereas the installation media from microsoft.com used the embedded key without any complaints at all.

I have no idea if this is also the case beyond Windows installations.

Where are Windows Sticky Notes stored in the filesystem

Windows Sticky Notes in the filesystem / How to back them up

In Windows 7, they were stored in a propritary binary format here:

%AppData%\Microsoft\Sticky Notes\StickyNotes.snt

In Windows 10 they are stored in a SQLite database her:

%LocalAppData%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite

https://www.winhelponline.com/blog/recover-backup-sticky-notes-data-file-windows-10/

 

Create a new Eventlog source

If you want to use a new “Source” in the Windows event log, you cannot simply start to use a new text.

A new Event-log source has to be created first – BEFORE you start to use it.

Run this command as an administrative user to create a new source – here named “NEW SOURCE”

eventcreate /l application /id 100 /t information /so "NEW SOURCE" /d "Creation of a new Event Source"

To create a new “Source” in the Windows event log, you need administrative privileges

Run a Windows scheduled task by hand

If you have created several scheduled Tasks in Windows, you may from time to time want to run some of them manually

The obvious solution is to open the Windows “Task Scheduler”, locate the proper scheduled task, right-click it and “run now”

An alternative is to copy the name you have given the scheduled task. Then you can always run the following command in a command-line

SCHTASKS /Run /TN "Start SQL Management Studio"

if the name of you scheduled task is “Start SQL Management Studio”

Windows (many versions) caches old AD-account information

Windows – both client and server, in many versions – caches old AD-account information.

Most often, this gives problems, when a user changes their username in AD, but on another server, the old username is cached and associated with the users SID. So when a username for a given SID is requested on the other server, the old username is returned.

The reasoning behind the functionality can be found here:

The LsaLookupSids function may return the old user name instead of the new user name if the user name has changed

The cache can be disabled by inserting DWORD 0 in registry-key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LsaLookupCacheMaxSize

This article gives no other method to reset the cache – apart from restarting the server.

Other users have found better solutions – such as running the short 2-line PowerShell given below, which updates the cached AD-information for the given user.

http://serverfault.com/questions/266180/purging-ad-principal-from-cache

$objuser = new-object system.security.principal.ntaccount “domain\<new account name>”
$objuser.translate([system.security.principal.securityidentifier])