Most people reporting this error are running the AnyWhere Access on Essentials 2016, or possibly 2012, for the first time. However, I have run into this twice in the past few months, rerunning the wizard to renew the public access SSL certificate on older Essentials 2016 servers. Perhaps this is caused by a recent update. Many report waiting a while resolves the issue, but I have not found this to be true.
JVH advise you need to add 2 registry entries to each of 4 registry keys. NOTE: if you are not familiar with doing so, editing the registry incorrectly can destroy your server. As always, back up the registry before starting.
There seems to be an issue with recent server versions where after promoting a server to be a Domain Controller you loose access to several key functions. The main one seems to occur when trying to access “Change adapter Options” which results in a pop up “Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item”. In addition, in some cases when you try clicking on management tools such as Gpedit.msc and Control Panel, nothing happens. You can to try to access these using “run as administrator” which doesn’t always work, or create a desktop icon for the app and click the advanced options check box for run as administrator, but I see these as tedious work arounds.
The issue seems to be related to UAC (User Access Control) which can be “tweaked” with Group Policy. Since this occurred after promoting to a DC, one should use the Group Policy Management console rather than the Local Group Policy editor.
Run the GP Management console and edit the Default Domain Policy or a Computer OU of your choice. Locate the following policy, and enable:
Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options || User Account Control: Admin approval mode for the built-in administrator account
Once changed, from an elevated Command prompt run:
If not prompted to do so, you will need to log out and back in.
You should now be able to access your various admin tools that were blocked before.
If you remote into a PC to run Sage, sometimes your local printer does not connect. To resolve this you need to open the Windows printers console on the computer running Sage and look for the appropriate printer and the “redirected #”. Then in Sage under Report & Form Options, choose the items you wish to print and beside them select the printer with the redirected # that matches the printer in the Windows printers console, as in the image below.
On many systems each time you reconnect to the remote computer a new redirected connection is created such that there are so many it can be near impossible to locate the appropriate redirected printer. See image below as an example.
To clear all these excess printers you can edit the registry. (As usual, back up the registry or at least the key before deleting and if not comfortable doing so, do not proceed as registry changes can corrupt your machine) To clean up the list of printers, on the computer running Sage, locate the registry key: HKEY_CURRENT_USER\Software\Microsoft\Window Nt\Currentversion\Printerports Delete all printer ports showing (redirected #). Do not delete those without (redirected #) Reboot the computer running Sage, reconnect, and select the newly redirected printer.
The past 8 or more years most of us have managed PC updates using WSUS (Windows Server Update Service) and Group policy. However, the structure of the modern office has changed to a large percentage of mobile employees who never ‘touch down’ at headquarters. If these devices do not connect to the domain they do not have updates applied.
A client who has not returned to the office in 18 months, and likely will not for the life of their laptop, recently asked how they could update their machine manually. Currently they were not able to do so as Windows Update showed “settings are managed by your system administrator”, in other words, by WSUS
It is quite simple to disable WSUS management in the registry, however remember if the device is reconnected to the domain, the WSUS policies will be reapplied. Therefore you may want to move the device to an OU not linked to the WSUS policy or remove the device in the policy under security filtering.
Disclaimer: Be aware making incorrect registry changes can have disastrous effects to the health of the device. Be sure to backup the registry before editing. To do so see the following Microsoft article; “How to back up and restore the registry in Windows” http://support.microsoft.com/kb/322756
Open the registry editor, by entering Regedit in the Start / Run box, and browse to: HKLM\Software\Policies\Microsoft\Windows\
Locate the WindowsUpdate Key and delete it
Reboot the PC (may take 2 reboots)
Now you can manually update and configure Windows updates to automatically check for and install updates directly from the Microsoft Update site
I recently had a user receive an error message; “Windows cannot load the user’s profile but has logged you on with the default profile for the system” when logging on t o a Windows 7 desktop. In the Event logs there was a matching Event ID 1505 with a Source “Userenv”. This is not O/S specific error, can be caused by numerous issues, and there are variations of the same error due to other problems. In this particular instance it appears it may have been caused by an interrupted backup during which the profile was locked to allow backup. To verify if a similar problem and resolve, follow the steps below.
Note: the following steps involve making changes to the registry. It is possible when editing the registry to damage your system. Only follow these steps if comfortable doing so and as always, create a restore point and/or backup the registry first, as per Microsoft’s instructions http://windows.microsoft.com/en-CA/windows7/Back-up-the-registry
Open the registry editor and locate the following key: HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList\
problematic profile. Two methods to do so are:
click on each profile and view the “ProfileImagePath” key for the appropriate profile name
download PSGetSid from the Microsoft link below and from a command line run: PSGetSid username
The problematic profile key will likely end with .bak such as; S-1-5-21-2037612603-1103315024-2874594402-1003.bak and there will be a matching profile key without the .bak extension, which is the temporary/default profile.
Assuming a .bak profile exists, rename the temporary profile something like S-1-5-21-2037612603-1103315024-2874594402-1003.tmp, and remove the .bak extension from the other.
Within the user’s profile key also check the sub-key “State”. If this is set to something other than 0
change it to 0.
Reboot the system.
Upon reboot Windows should select and use the proper user profile
Other potential solutions for Event ID 1505 and Source UserEnv: