There are a lot of enterprise management packages that help manage windows updates in a very good manner. Also with Configuration and Management tools, this can be managed as well. Example of this solution is Microsoft System Center Systems (SCCM).

Without solutions like SCCM etc, we find it difficult to centrally manage updates for server and client operating systems in Active Directory correctly. Group Policy can provide a limited way of achieving this functionality but not enough as it can often lead to other organizational problems. With Group Policy, here is it is configured and most times not sufficient for your organization’s need.

Launch the GPEditor via searching for gpedit.msc
- Navigate through Computer Configuration 
- Administrative Templates 
- Windows Components 
- Windows Update  

Locate the Configure automatic update. Here you will see that the date is missing and with this, GPO is not regarded as an optimal solution for installing Windows Updates.

Group Policy Draw Back
– Because GPO does not have a scheduled installation date rather than days of the week and the monthly categorization, as shown above, this solution does not make it very effective for managing Windows Updates.
– If you are not using WSUS but directly pulling updates from the Microsoft Update Catalog https://www.catalog.update.microsoft.com/Home.aspx
The biggest challenge here is, you cannot be explicitly withheld or push out updates immediately.
– The other strategy for system updates is to stick to maintenance times, and the best way to do that is to assign this setting at the Organisational Unit (OU) level. In this configuration, an OU would be created for a category of like servers. These OUs would all undergo their Windows Updates at the same time that is configured in the GPO for that OU.

If you do not have SCCM or any 3rd party application capable of performing this, the good news is that Windows Admin Center (WAC) is capable of performing this task.

Follow the following link to see the steps on how this is performed https://techdirectarchive.com/2020/02/05/scheduling-and-running-update-via-windows-admin-center/

System Insights is a new feature available the Windows Server 2019 and it brings local predictive analytics capabilities natively to Windows Server. These predictive capabilities are leveraged by the machine-learning model which locally analyses Windows Server system data, such as performance counters and events, providing high-accuracy predictions.

This helps reduces the operational expenses associated with reactively managing your Windows Server instances. Because each of these capabilities runs locally, all your data is collected, stored, and analyzed directly on your Windows Server instance, allowing you to use predictive analytics capabilities without any cloud connectivity.

In Windows Server 2019, System Insights introduces a set of capabilities focused on capacity forecasting, predicting future usage for computing, networking, and storage. To work with System Insights, you need currently Windows Server 2019. When the OS is installed, you can enable System Insights in two different ways:

• Through PowerShell
• With Windows Admin Center

I will be demonstrating how this is done effortlessly via Windows Admin Center below. When the Windows Admin Center is successfully installed, you will see System Insights added to the Tools section of the server that has it installed.

It comes predefined with 4 settings it will check up on:
– CPU capacity forecasting
– Network capacity forecasting
– Total storage consumption forecasting
– Volume consumption forecasting

You can simply select one and click on Invoke to actually generate the data required for the forecast. Unfortunately, if you run this on a fairly new machine [<2 hours], there’s a big chance you’ll run into this ‘notification.

Under tools
select System insights

This will launch the system Insight Window, where the tool can be installed that will give the forecasting capabilities.

Click on install and this will begin the install process as shown below.

When successfully installed, it prompts the various capabilities possible

Click on any of the capability name as shown below

Example: Let’s click on the Network Capacity Forecasting

Click on invoke on the top left under system Insights

Now under the status description, there will be entry as against the first image above.

To view the result, click on the Network Capacity Forecasting, here you should see the metrics if available.

Note: You can create a schedule on when it will run, without you having to invoke it

When you are done, click on close. See the image below for the result after successful mining of information (This usually take a while to populate as shown in the Status description).

Click on the capability name to view more details (output). Let’s take a look at the Network capacity/reporting, by clicking on this, it will display the overview of the Network capacity forecast (result). With these results, you can support and maintain your devices better.

PowerShell is configured to prevent the execution of PowerShell scripts on Windows systems by default. In order to run commands, one of the following systems must be taken into consideration. See how this is done via PowerShell https://techdirectarchive.com/2020/02/04/how-to-set-execution-policy/

To do this, open the Registry editor. 
– To change the execution policy for the current user, go to 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell 

Set the string value ExecutionPolicy to one of the following values:.

• Restricted
• AllSigned
• RemoteSigned
• Unrestricted,
• Undefined. 

To change the execution policy for the LocalMachine scope, Navigate to the path as shown below.

Currently, no value is set and none is currently available. To set the string value ExecutionPolicy to one of the following values: Create a new string and enter any ExecutionPolicy value you desire as below. Restricted, AllSigned, RemoteSigned, Unrestricted, Undefined. 

Create a new string and name it ExecutionPolicy

Now enter the desired value.

Press okay afterwards and that is all 😉

PowerShell is configured to prevent the execution of PowerShell scripts on Windows systems by default. The PowerShell execution policy is a safety feature implemented to controls the various conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts. In order to run and execute scripts, one of the following values must be taken into consideration. To see how this is done via the registry, see https://techdirectarchive.com/2020/02/04/how-to-set-the-powershell-execution-policy-via-the-registry-settings/

Below are the various values of policies that exist. 

• AllSigned: This runs the only script that is signed by a trusted publisher only. 
• ByPass: Configured to permit a certain script to run
• Default: By default, the Execution Policy is set to restricted for Windows devices and for server, it is RemoteSigned. 
• RemoteSgned: The script must be signed by a trusted publisher before they are permitted to run.  Scripts that you run from the local computer don’t need to be signed. There are no prompts when you attempt to run a script. 
• Restricted: In this mode, no PowerShell script is allowed to run on the device.  
• Unrestricted: In this mode, regardless of where they are created or downloaded from, these scripts are run on the devices. 
• Undefined (No execution policy): This value does not have the execution policy set. The effective execution policy is Restricted, which is the default execution policy.   

Scope: This specifies the scope that the execution policy is run on. The execution Policy can be run and set in various scopes as shown below. The effective execution policy is determined by the order of precedence as follows. See the screenshot below for more information.

• MachinePolicy 
• LocalMachine 
• Process
• UserPolicy
• CurrentUser 

Open PowerShell (This is usually advisable to be run in Admin mode) 

Type the following command and press the Enter key
- Get-ExecutionPolicy -List 
To view the currrent policy 
- use "Get-ExecutionPolicy" 

The Set-ExecutionPolicy cmdlet changes PowerShell execution policies for Windows computers. Here is how to see the PowerShell Execution Policy.

Type the following command and press the Enter key
- Set-ExecutionPolicy Unrestricted

Note: When you hit enter after the prompt, you can selected any of the options as follow; by selecting yes, or Yes to All or No. When you hit enter without choosing a value, the No (Nien switch) is selected automatically and the script will not run. Pay close attention to the script below as the position was taken by default and this was set to unrestricted.

Note: Set-ExecutionPolicy doesn’t change the MachinePolicy and UserPolicy scopes because they are set by Group Policies. The Set-ExecutionPolicy doesn’t override a Group Policy, even if the user preference is more restrictive than the policy.

Here is an example on how to set an execution policy to unrestricted and this will permit all scripts to be run on the device.

An example here which also a best practice measure, is to allow the script testwsus.ps1 to run only in order not to set the global execution policy to unrestricted as shown below.  

Set-ExecutionPolicy Bypass -File .\testwsus.ps1 

If you don´t want to set this parameter for the entire system you are able to start a powesehll session in unrestricted mode. 

set-executionpolicy unrestricted -command .\testwsus.ps1

Active Directory contacts include information about a person or business, such as phone numbers, email addresses, and fax numbers. Creating and managing AD contacts is vital for organizations, as contacts can be listed in a Global Address List (GAL) or another address list, allowing users to access contact information and send messages

Why would you want to create a contact in Active Directory (AD)?
– Contact is most times needed in AD when you have a member that is not a regular user in your organization, such as an external (3^rd party contractor). This will ensure a user account is not created for the user.
– Contact accounts will also help maintain a high level of security in your organization.
– Lastly, it will help save contact and help email software access the contact details.

Note: Contact only contains details about a person and does not contain the SID enabled on the user
Noe: This is similar to contacts in O365

Create a contact in Active Directory
– Under Tools,
– Launch Active Directory Users and Computers

Right-click on the OU, where you want the contact to be created.
– Click on New
– Click on Contact

And follow the dialog box displayed to perform the tasks.

When you have it created here, there is no need creating it again an Exchange Server as the exchange server will be able to access the details.

– To configure additional properties
– Right-click on the contact and select properties

Note: You can add the contact to the group etc., despite not having a SID.
Because it does not have the SID enabled, they are not granted access to the group they belong to but only on getting emails sent to the group they belong to.

Difference between contact and user object