SHIFT-WIKI - Sjoerd Hooft's InFormation Technology
This WIKI is my personal documentation blog. Please enjoy it and feel free to reach out through blue sky if you have a question, remark, improvement or observation. See below for the latest additions, or use the search or tags to browse for content.
Fix: Windows XP: The local policy of this system does not permit you to logon interactively
Summary: A fix to allow users to login remotely on Windows XP. It's old, that's what makes it fun.
Date: Around 2015
Refactor: 16 January 2025: Checked links and formatting.
You get this error when a user is not added to the remote desktop users or you haven't allowed remote desktop users to… well actually… to login remotely. To do so, first add the group to the Remote Desktop Users list:
- Go to Start → Settings → Control Panel.
- Double-click System, and then on the Remote tab, click Select Remote Users.
- Click Add and type the user account name, and click OK.
Secondly, make sure that the Remote Desktop Users group has sufficient permissions to log on through Terminal Services. To do this, follow these steps:
- Click Start, click Run, type secpol.msc, and then click OK.
- Expand Local Policies, and then click User Rights Assignment.
- In the right pane, double-click Allow logon through Terminal Services. Make sure that the Remote Desktop Users group is listed.
- Click OK.
- In the right pane, double-click Deny logon through Terminal Services. Make sure that the Remote Desktop Users group is not listed, and then click OK.
- Close the Local Security Settings snap-in.
AD DC Role Seizing
Summary: A post about seizing Active Directory Domain Controller roles, also known as FMSO.
Date: Around 2014
Refactor: 13 February 2025: Checked links and formatting.
Whenever you're in the situation the AD Domain Controller roles (FMSO) are not what they should be you can always seizes the roles you need. This small howto shows you how.
Note: This is a quite common scenario after doing a test failover with Site Recovery Manager 5.1.
Fix: Ldaperr: DSID-0C0903AA comment: AcceptSecurityContext error data 525 v1772
Summary: A fix for LDAP error 'Ldaperr: DSID-0C0903AA comment: AcceptSecurityContext error data 525 v1772'
Date: Around 2013
Refactor: 16 January 2025: Checked links and formatting.
While tooling around creating this page I came across this very annoying error:
autoyast:~ # ldapsearch -h 10.10.10.101 -D CN=saldap,CN=Users,DC=adldaptest,DC=local -w ******** -b DC=adldaptest,DC=local -x uid=sjoerd
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772
Turned out that when doing AD LDAP binds like this, you need to use the user principal name (userPrincipalName):
ldapsearch -h 10.10.10.101 -D saldap@adldaptest.local -w ******** -b DC=adldaptest,DC=local uid=sjoerd
This wiki has been made possible by:
Fix: CommVault: Invalid CS Cache
Summary: Fix the situation in which the CommServe cache has become corrupted on a windows client.
Date: Around 2019
Refactor: 2 January 2025: Checked links and formatting.
I wanted to update a CommVault client and received this error:
It appears that CS cache is corrupt, delete the cache, download updates again and retry.
And when I checked the updates configuration in the commcell console I saw a message confirming that the CommServe Cache was invalid:
The steps to solve this are the following:
- Manually delete the entire directory and recreate the directory
- Login to the CommCell Browser, right-click the CommServe icon, click All Tasks → Download Automatic Updates.
- From the Download Updates Job Options dialog box, click Run Immediately
This will start the download from the updates if you have the updateserver configured. When the downloads are complete you will have a valid CommServe Cache again:
This wiki has been made possible by: