So you go to login to via RDP to a server, workstation or remote PC and you get this error:
Not to worry, here is the fix as well as the why.
First run windows update on your local system and try again.
Quick fix: (not secure)
- Use the Windows+R key to open the Run Command. (If you keyboard lacks the windows key you can use Ctrl+Alt+DEL, open task manager, then click file and "Run".)
- In the run command type in gpedit.msc which will open the Local Group Policy Editor.
- Expand Computer Configuration > Administrative Templates > System > Credentials Delegation.
- Update the Encryption Oracle Remediation policy to Enabled, then change Protection level to Vulnerable.
- After doing this it is advisable to update your remote system and switch these settings back.
Proper fix: (secure)
Update the remote server, in some cases the remote server may show that is it up to date in which case you may have a compromised system and will need to follow the following steps in order to force the update after which you should do a full scan on the system for potential malware.
After the May 2018 update RDP no longer connects by default to a remote system that is not running the CredSSP update.
You've just received notice that your Active Directory server is being used as part of a wide scale dDoS attack. Here is how you can fix it.
Go to the firewall settings on the active directory server or reported server IP and look for the following rules.
- Active Directory Domain Controller - LDAP (TCP-In)
- Active Directory Domain Controller - LDAP (UDP-In)
- Active Directory Domain Controller - LDAP for Global Catalog (TCP-In)
- Active Directory Domain Controller - Secure LDAP (TCP-In)
- Active Directory Domain Controller - Secure LDAP for Global Catalog (TCP-In)
For each of these alter the rule by choosing the Scope tab and entering only IP addresses that should have access to LDAP information. For example, Microsoft Exchange Servers within your network that need access to LDAP.
For assistance securing your network or if you are looking for hosted exchange services check out Area51.mn.
This error appears in the event viewer when the scheduled task "ScheduledDefrag" runs.
Cause: In most cases this is cause by the -k switch which tells the defrager to perform a slab consolidation on the selected volume. This will cause an error for slabs that are less than 8 MB, and will commonly toss an error on HyperV VM's.
Solution: remove the -k switch from the task.
- Open scheduled tasks, Microsoft, windows, defrag: "ScheduledDefrag"
- Now click properties, actions, edit [start a program]
- under add arguments(optional): remove the -k and click "ok", "ok"
That's it, your done.
After installing exchange 2013 and migrating clients over to the server you may notice Microsoft® SharePoint® Search Component or noderunner.exe running multiple instances with high memory usage. This is because Microsoft has integrated parts of sharepoint into exchange 2013. This process runs when accounts are first migrated and periodically to index email data stores for OWA in order to make search results fast, very fast.
You can disable Microsoft Exchange Search Host Controller service if it is causing an issue. In some cases it can consume an extremely high amount of memory causing the "Microsoft Exchange RPC Client Access" to fail and get stuck in a starting state. In which case the best solutions are to:
- Increase the amount of RAM on the server.
- Set the server to restart when "Microsoft Exchange RPC Client Access" fails.
- Disable the "Microsoft Exchange Search Host Controller service".
This is an obvious flaw in the design of exchange 2013 server.