I just found out that on my Debian 11 VM in PowerShell the key combination Ctrl+C does not work.
The script is not terminated by this, unlike expected.
I added the following code and now it works.
add-type -typedefinition @"
public class CtrlCHandler
public static void Main()
System.Console.CancelKeyPress += (s,e) => System.Diagnostics.Process.GetCurrentProcess().Kill();
When I opened the home page of the newly created root site collection everything seems fine. But when navigation to some link in the quick launch I only got empty / blank pages. No errors in the Developer tools. Just no content.
(There was almost no content in the HTML DOM. Just the <head> tag with some content and the <body> tag with 1 <script> tag…)
After searching in the SharePoint logs I found this error:
Error encountered when creating uri from baseUrl /_layouts/15/next/odspnext/.
Pull the latest “all-in-one” Docker image of Casdoor.
docker pull casbin/casdoor-all-in-one
Now you create the container…
docker run -d -p 8000:8000 --name casdoor -v ./casdoor-data:/var/lib/mysql casbin/casdoor-all-in-one
Three comments on that:
The Casdoor portal on your machine can be accessed using http://localhost:8000. If you need another port that change “8000:8000” to something else like “9000:8000”. The second port is internally used inside the Docker container. Do not change that. The first port is the published one on your machine.
Casdoor is an identity provider. You will need to create identities in it. Of course you do not want to do that again and again. Therefore it’s a good idea to put the data of the Casdoor container into Docker volume. If you later recreate the container the volume will remain on disk.
You ask: “Where is the Docker volume located on disk on WSL 2”? Good question! WSL creates a hidden mount point (?) that you can access on Windows by accessing \\wsl$ in the Explorer. Then you can navigate to the correct folder that contains the volume of Casdor: \\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\casdoor-data
Today I could solve a wired problem. It belongs to User Profile “AD Import” on SharePoint Server 2019.
The profile overview of a person stated two different information: At the top there was the correct department but in the organizational chart the person had the wrong manager and so a wrong department information.
The organizational chart is generated from the “Manager” attribute of the SharePoint user profile.
In the profile I saw a correct “department” attribute value but a wrong “manager” attribute value.
I started a “Full AD Import”.
In the SharePoint log I saw an exception with the message, that a XML file in the SharePoint timer cache on one server could not be changed.
So first I refreshed all timer cache folders on all servers: Stop Windows service “sptimerv4” on every server. Find the subfolder with file “cache.ini” below c:\programdata\microsoft\sharepoint\config. The folder has a GUID as name. Than delete all file but cache.ini. Than set the content of cache.ini to “1” (without “”) and restart the service “sptimerv4”. The cache folder gets filled again. The content of “cache.ini” will be set to a valid value…