active directory, Exchange, microsoft, Windows Server
Sometimes when performing exchange server updates after rebooting the server it will hang on ‘Getting Windows Ready’ then sometimes when logging in it may lock up again and become unresponsive.
This is a common issue with Exchange 2013 and Windows Server 2012 R2 Operating System.
Follow the guide below to resolve this issue.
I restarted VM few times, but the Exchange Server VM was unusable.
The best solution is to enter Boot Menu and run VM in Safe Mode.
For this we have to boot VM from Windows Server 2012 R2 ISO and instead of Install option, we select Repair your computer.
After selecting Troubleshoot, we enter Command Prompt.
We enable Boot Menu on our Windows Server 2012 R2 OS of Exchange Server VM by entering commands:
bcdedit /set {bootmgr} displaybootmenu yes
bcdedit /set {bootmgr} timeout 15
After VM reboot, we can enter Boot Menu by pressing F8 and select Safe Mode option.
In Safe Mode Exchange Server VM starts without problems.
Go into Services and disable all Exchange Services on VM (by changing Start-up Type of services to Manual). After this reboot the VM in normal way and machine will start.
Re-enable Exchange Services again (by changing Start-up Type of services to Automatic) and reboot VM.
The Exchange Server should now boot up straight away without being stuck at the ‘Getting Windows Ready’ screen
active directory, compliance, gpo, group policy, IT Cyber Security Technical Knowledge, microsoft, networking, ransomware, Windows Server
Create Group Policy to Whitelist Applications – Ransomware prevention
Recommended to test Whitelisting in a test environment before deploying in production environment. Purpose is to Block Ransomware, Block Java Updates You will need to manually add Whitelist entries for each new Java Update you wish to install
Go to https://java.com/en/download/
Take note of the latest Java Version (eg, 8u301)
Login to your to a server that can Access/Create/Edit Group Policy objects
Open the run command, type in gpmc.msc – Click OK
Right click on the Organizational Unit you wish add the Whitelist to, Select the first option.
(Create GPO)
Enter a name for the Whitelist, Click OK (i.e CryptoLocker/Ransomware Prevention)
Link the newly create GPO to any other Organizational Units you want to be added to the GPO.
(eg. Right click on Computers OU, ‘select Link an Existing GPO…’ then select the new GPO)
Right click on the GPO, click Edit…
Drill down in; Computer Configuration >> Policies >> Windows Settings >> Security Settings >> Software Restriction Policies
Right click on Software Restriction Policies, Select the first option
Right click on Additional Rules, Select New Path Rule…
Enter the following path: %localAppData%\*\*.exe
Security Level = Disallowed
Click OK
Create Additional Path Rules for the following paths:
%localAppData%\*.exe
%AppData%\*.exe
%AppData%\*\*.exe
%Temp%\*.zip\*.exe
%Temp%\7z*\*.exe
%Temp%\Rar*\*.exe
%Temp%\wz*\*.exe
Your list should look like this:
Exit out of Group Policy Editor.
Create another GPO called Cryptolocker/Ransomware – Whitelist Allow (Link to same OU’s as previous GPO)
Right click on the GPO, click Edit…
Drill down in; – Computer Configuration >> Policies >> Windows Settings >> Security Settings >> Software Restriction Policies
Right click on Software Restriction Policies, Select the first option
Right click on Additional Rules, Select New Path Rule…
Under ‘Path:’ enter the path of the Java Installer you wish to allow:
%localappData%\temp\jre-8u301-windows-i586-iftw.exe
Depending on which version of Java you are updating, replace ‘8u91’ with the version you want to allow.
Set Security Level to ‘Unrestricted’
Enter an appropriate description name.
Click OK.
Verify that new Path Rule has been added to Whitelist.
Close GPO Editor.
Refresh Group policy Management
Go down to the Whitelisting Çryptolocker/Ransomware – Whitelist Allow GPO, click on it once
In the window on the right select ‘Settings’ from the tabs.
Drill down to; Computer Configuration >> Policies >> Windows Settings >> Security Settings >> Software Restriction Policies/Additional Rules
Verify that new Path rule is shown in Policy List.
Exit Group Policy Management.
Go to a machine what is linked to the GPO to test whitelist.
Run Java Updater/Installer
Note the successful installation of Java
If fails = Perform forced Update to GPO
From Administrative Command Prompt,
gpupdate /force
active directory, auditing, compliance, microsoft, networking, shared folder, windows 10, Windows Server
Audit all access to folders and/or files on a server or workstation.
Log onto the server/workstation that you wish to enable auditing on.
Open Local Group Policy Editor.
CTRL + R
gpedit.msc
Browse to the following location: – Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy
Double click ‘Audit object access’
Select Success and Failure
Click Apply then OK
Exit Local Group Policy Editor
Navigate to the folder/file you wish to track permission changes.
Right click the folder/file then select Properties.
Select the Security tab then select Advanced
Select the Auditing tab then select Continue (if prompted)
Click Add
Click Select a principal
Type ‘everyone’ then select Check Names. – Click OK
Set the Type: to All
Untick the default auditing permissions and only select ‘Change permissions’ – Click OK
Click OK Twice more.
Open up cmd or powershell as ADMIN
Execute the command: gpupdate /force
Auditing is now implemented on the specific folders/files.
To check audit logs open Event Viewer.
Select the Security Logs
Filter the logs based on Event ID 4670
active directory, licensing, microsoft, rds, rwa, Windows Server
You may want to move the existing RDS licenses to a new server to put an old operating system out of production or just upgrade in general.
Login to the server as an administrator
Install the Remote Desktop Licensing Server and Gateway Role via Server Manager
Once installed open Remote Desktop Licensing Manager from Server Manager
Add the current server into the Terminal Server License Server group as per below,
Select Add to group.
Right click on the server name and select Activate Server
Select Next at the Connect Method screen, (Automatic connection (recommended) is the default)
Enter the relevant information (Company Information) then select Next
Proceed to the next page and fill out additional information.
Click Next and the server will activate
On the new licensing server add the old server into the console by select Action > Connect
Enter the IP Address of the old licensing server.
The old server should now be visible on the new server.
To get the licensing ID right click on the old server and select properties
To get the licensing ID right click on the old server and select properties
Select the new licensing server, then go to Action > Manage licenses
Once the window opens select Next
Select the first option as shown below.
Select the checkbox and select the operation system the old licensing server is running.
Enter the license server ID previously copied, Select Next
Tick the checkbox to agree to manually remote the licenses from the source server then select next.
If the old licensing Server is running Windows Server 2008 not 2008 R2 you will need the original RDS CAL licenses (Refer to documentation) to apply to the new licensing server as a 2008 server cannot automatically migrate the RDS CAL licenses, only 2008 R2 and above.
If the old licensing Server is running 2008 R2 or above proceed through the wizard to migrate the RDS CAL licenses.
After you have verified the licences are activated and functional you can deactivate the old RDS licensing server.
Once deactivated uninstall the RDS licensing role via Server Manager
active directory, hyper-v, microsoft, networking, rds, rwa, Windows Server, windows update
Remote Web Access (RWA) SSL Gateway not working after Windows Update
After installing Windows updates you may get the following error when trying to logon to RDS via RWA (Remote Web Access)
Log into the Domain Controller
Open Powershell as ADMIN
Run the following command:
dism /online /Enable-Feature:Gateway-U
Open the Remote Desktop Gateway Manager from Administrative Tools > Remote Desktop Services.
Right click the server name then select Properties
Select the SSL Certificate tab then select Import Certificate…
Select the correct SSL certificate for the Remote Desktop Gateway then select Import
Click Apply then OK
Close Remote Desktop Gateway Manager
Test connectivity via RWA
active directory, microsoft, networking, Windows Server
NOTE: Take a backup and/or snapshot of the VM before making any changes.
When setting up Active Directory, the IT Administrator is given an option to select the folder path to copy the Active Directory database files to. It is advised to always to use a separate partition to save the database files instead of using the default C:\Windows\NTDS\ folder path. This provides an easier opportunity to move the Active Directory database to different location should disk space on the server dry up.
In this Step-By-Step, the lab DC currently stores its AD database files in default C:\Windows\NTDS\ folder. Steps will be detailed amidst this post to move it to a new disk added to the server. The new path it will be moved to will be E:\ADDB
Step 1: Prepping Active Directory to be moved
- Log in to the primary domain controller as domain or enterprise administrator
- In Server Manager, navigate to Tools > Services
- Once mmc loads, right click on Active Directory Domain Services and click stop
4. When asked if it’s okay to stop associated services, click Yes to continue.
Step 2: Moving the Active Directory database
- Right click on start button and click on Command Prompt (Admin)
2. Once command prompt is visible, type ntdsutil and press enter
3. Next type activate instance ntds and press enter
4. Then type files and press enter
5. In files maintenance the command to move the db is required. As mentioned earlier, the need to move the database to E:\ADDB.Type the following command to enable the move: move db to E:\ADDB
Note: Remember to use quotations (“”) should the path contain a space
6. Once the database files are successfully moved, type the following command to move the logs: move logs to E:\ADDB
7. Once the move has successfully completed, Return to the initially used services.msc and start Active Directory Domain Services stopped in Step 1
Browse to the new directory where the database files were transferred to confirm they have been transferred successfully.
Restart System.
Test logging in as a AD user.
