Scenario

• You are running Exchange 2007 or Exchange 2010
• Your client PCs are running Outlook 2007 or higher
• You add an SSL certificate to your Exchange Server so that users do not see a certificate warning when connecting to your Outlook Web Access (OWA) web site.
• Your Outlook clients then start reporting a certificate error as per below.

"The name on the security certificate is invalid or does not match the name of the site"

This message appears frequently, usually within a few moments of opening Outlook.

Cause

The cause is that Outlook clients are passed the certificate by the server, and have noted that the webmail address of the certificate does not match the internal name of the server.

For example:

Internal Server name: exchange.local

Webmail address: http://webmail.company.net/owa

Recommendations

Certificates are now usually not available which reference domains which companies do not own. For example, you will likely not be able to purchase a certificate that contains your webmail address (a domain which you own) and your internal addressing scheme (for example, .local) which you do not own.

One solution to this is to use an internal addressing scheme which matches the domain that you own. For many companies, this is not practical without an entire forest migration.

Solution

The solution is to modify settings within the Exchange server so that Outlook clients reach the resources that they need to using the external address.

Steps:

• Use an NSLOOKUP command to ensure you have the correct internal IP address for your Exchange server. For example, exchange.local resolves to 10.0.0.10.
• Add a DNS zone and host record which ensures that the webmail address of your Exchange server resolves to the same IP address. This means that when you do an NSLOOKUP against webmail.company.net it must resolve to the same IP address of 10.0.0.10.
• Modify the following commands to include your local server names and webmail addresses (substitute the server names and web address in red)
• Run the commands on your Exchange Server Power Management Console

Set-ClientAccessServer -Identity exchange -AutodiscoverServiceInternalUri https://webmail.company.net/autodiscover/autodiscover.xml 

Set-WebServicesVirtualDirectory -Identity "exchange\EWS (Default Web Site)" -InternalUrl https://webmail.company.net/ews/exchange.asmx

Set-OABVirtualDirectory -Identity "exchange\oab (Default Web Site)" -InternalUrl https://webmail.company.net/oab

This last command is not required on Exchange 2010:

Set-UMVirtualDirectory -Identity "exchange\unifiedmessaging (Default Web Site)" -InternalUrl https://webmail.company.net/unifiedmessaging/service.asmx

Testing

Always test changes immediately, ensuring that both Outlook clients and webmail clients function correctly.

If you require additional informatin please contact Stone support. A range of support services are available to assist customers.

Applies to:

• Outlook 2007 and Exchange 2007 or Exchange 2010

Scenario

When you run Windows Update on a Microsoft Windows Server with Hyper-V - the "host" - this may update the virtual server components within Windows. This may then require that you update the virtual tools, software and drivers that run inside the Virtual machines running on that Host. These tools, software and drivers are known as the "Integration Services".

In this article:

• Recommendations
• Considerations Before Updating Hyper-V Integration Services
• How to Check if an Update is Required
• How to Upgrade the Integration Services

Recommendations

• It is highly recommended to always have Integration Services up to date inside all virtual machines. Loss of network connectivity, storage performance or overall virtual machine performance can be experienced if the Integration Services are out of date or damaged.
• Never uninstall the Integration Services prior to an update. Integration Services provide network connectivity, display driver experience and storage drivers as a link to the Host operating system to be able to monitor and manage the virtual machine. Rather, perform an upgrade installation as below.

​Considerations Before Updating Hyper-V Integration Services

• Updates to Integration Services will require Virtual Machine ("guest") reboots.
• Plan updates to Integration Services as part of your regular systems maintenance cycle first.
• Always perform Windows Updates on your Host hardware first, to make the latest Integration Services available to Virtual Machines.
• Check the "Default Stop Action" action on your Virtual Machine settings to ensure that this is set to Save or Shutdown, rather than Turn off.
• Test Windows Updates on a test, non-critical server first.
• Running a Windows Update on your Host will likely require a reboot to the Host.
• When the Host is backup, run Windows Updates on your Virtual Machines, and Integration Services updates.
• These updates and reboots will require a period of downtime for the Hosts and virtual machines. Plan downtime where users do not need to access the systems.

How to Check If an Update is Required

• Open the Hyper-V Management Console
• Click on each virtual machine, checking the Integration Services status in the Summary tab

​

How to Upgrade the Integration Services

• Open a Virtual Machine Connection (also known as the console) to the virtual machine you wish to update.
• Click on Action, and then Insert Integration Services Setup Disk.

• Inside the virtual machine, find the virtual optical drive in Windows Explorer.
• Right hand click and choose Install Hyper-V Integration Services.

​​

• Follow the installation prompt to upgrade the Integration Services.

• Restart when prompted.

• When the virtual machine has rebooted, the Summary tab should now show that Integration Services are up to date.

Applies to:

• Microsoft Windows Server with Hyper-V Virtualisation

Use the method below to push out a computer startup script via Group Policy. Computer startup scripts are a useful way of making changes that need to happen regardless of which user is logged on.

This article is intended for system administrators who are new to using group policies.

The example below deploys the LANPWR.VBS script to disable a LAN or wireless LAN adapter's power management.

• Find a suitable machine that you can use for test purposes.
• Log on to your server as an Administrator
• Open up Server Manager > Active Directory Domain Services > Active Directory Users and Computers
• Find your test machine in Active Directory, and ideally, create a sub OU (organisational unit) to test the new setting. For example, the machine WIRELESS-PC below has been moved into the "Test_Laptops" OU which has been created just for testing.

• Open up the Group Policy Management tool by clicking Start, and typing in gpmc.msc. Then click on gpmc.msc that appears in the search results.

• Find the OU containing the test machine

• Right hand click on the OU name and then left click on "Create a GPO in this domand, and Link it here..."

• Give the new policy a name that is relevant to the settings it will contain

• Now right-hand click on the new policy that has appeared, and left click on Edit

• A new window will open. This list settings which can be applied to Computers - the machines - and user settings. Expand the tree of settings under "Computer Configuration" to find Policies, then Windows settings, and then finally Scripts (Startup/Shutdown).
• In the right hand Window, right-hand click on Startup and then left click on Properties.

• Click the Add button.

• Click Browse.

• Using Windows File Explorer, copy the script file that intend to use (lanpwr.vbs in the example) and then paste the file into the "Browse" window for the script, by right hand clicking on a blank part of the window, then left clicking on "Paste".

• Then make sure you select the intended file (lanpwr.vbs in the example) and click on Open.

• Ensure that the Script Name field has the name of your script, then click OK.

• You should now see your script added to the Startup Properties. Click on OK again.

• Thats it, you have now added your policy settings. You can close the Group Policy Management Editor window.
• Back in the main Group Policy Management screen, hit F5 to refresh the view, then click on your Policy and review the settings tab to ensure your policy has been submitted.

Things to Remember

• New policies might not be applied to systems straight away, even after a reboot (use the GPUPDATE /FORCE command from an Administrative command prompt to make this quicker)
• Some scripts themselves might take an additional reboot to take effect.
• Using a computer startup script is a great way of enforcing a setting no matter what subsequent software is installed or whatever changes users make.

Applies to:

• Networks running Windows Server with Windows clients.

How to Delete Old User Profiles on Workstations Across a Network

Old user profiles can consume large amount of space on shared network computers. This can be critical on some machines with relatively small Solid State hard drives.

Its a good idea to delete old user profiles from shared network Windows PCs to ensure that the drives do not run out of space. A number of methods have been around for some time, however recent changes to Windows 10 have broken a lot of these.

The attached Powershell script can be deployed via Group Policy as either a scheduled task, or a Computer Startup script.

• The script can be configured with the maximum profile age. Profiles that have been modified after that date will be removed
• You can specify that the script should not run on Windows Server operating systems
• Lastly, you can specify a list of accounts for which the profile should never be deleted

# Delete old User Profiles
# Andrew Sharrad 14/5/2020, 17/5/2021, 09/03/2022

# Please test before widescale deployment

#The list of accounts, for which profiles must not be deleted
$ExcludedUsers ="Public","Default","itadmin"
$RunOnServers = $false
[int]$MaximumProfileAge = 120 # Profiles older than this will be deleted

$osInfo = Get-CimInstance -ClassName Win32_OperatingSystem

if ($RunOnServers -eq $true -or $osInfo.ProductType -eq 1) {
    New-EventLog -LogName Application -Source "Stone Profile Cleanup" -ErrorAction SilentlyContinue

    $obj = Get-WMIObject -class Win32_UserProfile | Where {(!$_.Special -and $_.Loaded -eq $false )}
    #$output = @()

    foreach ($littleobj in $obj) {
        if (!($ExcludedUsers -like $littleobj.LocalPath.Replace("C:\Users\",""))) {
            $lastwritetime = (Get-ChildItem -Path "$($littleobj.localpath)\AppData\Local\Microsoft\Windows\UsrClass.dat" -Force ).LastWriteTime
            if ($lastwritetime -lt (Get-Date).AddDays(-$MaximumProfileAge)) {
                $littleobj | Remove-WmiObject
              #  $output += [PSCustomObject]@{
              #      'RemovedSID' = $littleobj.SID
              #      'LastUseTime' = $litteobj.LastUseTime
              #      'LastWriteTime' = $lastwritetime
              #      'LocalPath' = $littleobj.LocalPath
              #  }
            }
        }
    }

#$output | Sort LocalPath | ft
#$output | Sort LocalPath | ft * -AutoSize | Out-String -Width 4096 | Out-File -filepath "C:\MyOutput.TXT" -append -Encoding Unicode
    Write-EventLog –LogName Application –Source "Stone Profile Cleanup" –EntryType Information –EventID 1701 -Category 2 -Message ("Profiles older than $MaximumProfileAge days have been cleaned up")
}

Applies to:

• Windows computers running on a network

Group Policy User Login Scripts

This type of login script has long been used to assign resources or settings to users which cannot easily be deployed through other group policy settings. Traditionally, group policy user login scripts are run as soon as the user logs in.

Starting with Windows 8.1 and Server 2012 R2, Group Policy login scripts run at default 5 minutes after login. This means that if your login script carries out essential user environment preparation work, the client may be unable to use their session as intended for 5 minutes.

Solution

Deploy a Group Policy Computer setting to override the delay. You will need to be running Server 2012 R2 to easily deploy this policy.

The policy is located in: Computer Configuration > Policies > Administrative Templates > System > Group Policy - Configure Login Script Delay. Set this to Disabled to eliminate the delay.

Example below.

Note: This problem does not apply to user login scripts defined on the users active directory account Profile tab.

Applies to:

• Products running Windows 8.1 / Windows Server 2012

How to Create a PFX Certificate File from a PEM File

Problem

Some certificate authorities (such as Let's Encrypt) only supply certificate in the form of a PEM file, which is not usable by many Windows services.

In the case of Let's Encrypt, the PEM file may not have been generated as a part of a certificate signing request.

How to Convert PEM to PFX

• Install the latest stable Open SSL. The main page is here or you can find good Windows binaries here.
• Copy the PEM file to the OpenSSL binary folder, such as C:\Program Files\OpenSSL-Win64\bin
• Open an administrative command prompt or Powershell window to that folder
• Type in:

.\openssl pkcs12 -export -out result.pfx -inkey mypemfile.pem -in mypemfile.pem

• You will be prompted for a PFX password as part of the process. You must securely store the password with the PFX file to be able to use it.
• Above, the -inkey command is used to input the private key. If you have a separate certificate signing request (CSR) this would likely not be in the .PEM file, but would be in a separate .CRT file:

.\openssl pkcs12 -export -out result.pfx -inkey mycsrkeyfile.crt -in mypemfile.cer

Also see here.

Applies to:

• Windows Server services that require a PFX certificate that includes the private key

The User Profile

In some situations it may be necessary to delete a user's network profile. This may be required when the profile has been corrupted. When roaming profiles are used, when a user logs onto a machine, their profile is downloaded from the server to the local machine. This means that when the profile needs to be deleted, it is recommended to delete the profile from the network server and the local machine. Otherwise, on the next login, the user will may be given the cached local copy of the profile and this will be copied back up to the server when the log out.

Deleting the Profile from the Server

• First, ensure that the user is not logged on to any machine.
• Next, use the Active Directory users MMC to determine where the user profile is stored on your network. (P.S. if this setting is blank, the profile location is likely controlled by a group policy, and the profile folders are being re-directed. In this situation, you will need to use the Group Policy editor on the server to determine the redirected profile folder location).

The user profile path above shows that the profile is stored on the server "master" and the share name is profile$.

• Connect to the server that contains the profile share and find out where the share is located.
• To do this, open server manager, and then open File and Storage Services.

• Then click on Shares. Find the share name that was referenced in the users Profile Path setting, in the example this is Profile$.

• This tells you the physical location of the Profiles folder.
• Open that folder, and then find the users individual profile folder.

• Profiles created on machines that use Windows Vista or newer will have a folder name that ends in ".V2".

• Go into the users individual profile folder. The primary folders and files that need to be deleted are the Appdata folder, as well as the user's individual registry file - NTUSER.DAT.

• Profile information should be stored in a separate location to the user's documents, but this is not always the case. Double check that there are no folders called "Documents", "Pictures", "Videos", "Music", "Downloads" or "Favourites". Check that no user documents are stored in the users profile folder. If there are, then you will need to manually delete Appdata and NTUSER.DAT - but ensure that you do not delete anything which could contain the user's documents or work.
• Assuming that there are no documents folders or user work folders, delete AppData and the user registry files.

Deleting the Profile from the User's PC

We recommend that after deleting the profile from the server that you delete the users cached profile on their PC.

• Logon to the PC as a local administrator
• Run Regedit
• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
• Click on the long registry entries under profile list until you find the registry key that belongs to the user for which you want to delete the profile. The username is in the right hand window.
• This Profile Image path setting confirms where the users profile is stored on the machine - in this example, C:\Users\Test.

​

• Delete the registry key.

• Now, browse to C:\Users\<username> in this example, Test
• Make sure that Hidden folders are being shown, in file Explorer.

• Confirm that the user's folder does not contain any user documents or work, including checking for folder names such as "Documents", "Pictures", "Videos", "Music", "Downloads" or "Favourites". If these folders exist, you should check if they contain any users work or settings and confirm if the network user's home folder contains the most recent copy. These folders should not contain any information on the local PCs C drive if user folder re-direction has been properly configured on the network.
• Delete the C:\Users\<username> folder when you are happy that it does not contain any user documents or files which are not on the server. If you use unsure, it may be better just to delete C:\Users\<username>\AppData and C:\Users\<username>\NTUSER.DAT.
• Now you can ask the user to logon to their machine again, and check that their profile issue is resolved. When they logoff, a new copy of their profile should be uploaded back to the server.

Applies to:

• Domain networks with Roaming profiles and redirected folders.

Problem

Libraries are a feature of Windows 7 and later which allow multiple locations to be grouped together for the user to save or find documents.

On a managed networks some of the default library locations allow users to save content to the local machine's C drive even when the Document folders have been redirected, and even when access to the local C drive has been hidden. The default library locations include the user's redirected document locations etc., and also the machines Public library locations such as C:\Users\Public.

Users could inadvertently save content to the local machine's C drive if either the network location becomes unavailable, or by selecting the incorrect library as the default save location. If the users then switches machine, the content they saved will become unavailable to them. Additionally, the content they saved may become available to other users.

How to Remove Public Libraries

To prevent users from saving to Public library folders, some system administrators have used group policy registry hacks to turn off Windows 7 library features altogether. This is not recommended as Windows needs library features to use search and indexing properly, and also turning Public libraries back on after using this method is not easy.

Instead, a better method is to use the Microsoft SHLIB utility to remove the Public library from the users profile, using a user login script deployed using group policy.

An example script is attached to this article; you will need to modify the batch file to show where you have placed a copy of SHLIB on the network.

The public library location may be available on the users first logon only, until the setting is removed from their profile. Subsequent logons shouldn’t have the public library locations.

The file is also available here.

Applies to:

• Desktop systems running Microsoft Windows 7 as part of a domain network.

Problem

Operating system deployment fails with the following error:

 "The Computer Restarted unexpectedly or encountered an unexpected error. Windows Installation cannot proceed. To install Windows, click "OK" to restart the computer, and then restart the installation."

Resolution

On the screen with the error message above try the following steps:

1. Hold down "Shift + F10" to open the command prompt
2. On the command prompt type "regedit" with no quotes to open the Registry Editor
3. Go to:- HKLocal machine -> System ->Setup ->Status -> ChildCompletion
4. Highlight ChildCompletion and on the right you will see "setup.exe"
5. Double click "setup.exe" and verify the value is set to "1"
6. Change the value to "3"
7. Close the registry editor and close the command prompt.
8. Click OK on the error message and now the installation process should complete.

Applies to:

• Deployments of Windows 7 using SCCM 2012.

The Problem

Legacy Windows XP clients run at best Internet Explorer 8. You may experience problems when trying to push out Proxy and Homepage settings through Internet Explorer Group Policy Preferences, or Internet Explorer Maintenance (Policies > Windows Settings > Internet Explorer Maintenance). The settings may not apply and an error message may not be logged in the system event log.

This can be caused by:

• The Internet Explorer Maintenance option is not available to be configured through the Group Policy console on a server, when the server is running IE10 or newer.
• Internet Explorer preferences can be ignored by client computers or user logins, especially if a previous computer policy has been applied, or if the Windows XP Group Policy Preference client is missing.

Solution

• Attempt to push out the setting using Internet Explorer Preferences or Registry Preferences settings first - install the GPP client if necessary. These allow automatic background refreshes of settings.
• Don't forget to ensure that there is no lingering Internet Explorer Maintenance policy in place. If necessary, examine the Machine policy files in C:\Windows\SYSVOL\domain\Policies
• If Internet Explorer Group Policy Preferences doesn't work, try using a User Login Script which imports a registry file. The registry file contains proxy and home page settings.

A sample registry file and script is attached. Edit the registry file with Notepad to add your proxy settings and change your Homepage.

This method is designed for Windows XP however it may also work for Windows 7 clients. If attempting to use this with Windows 7, please test thoroughly and again ensure that you have only one method applied to make the change (including both user and computer settings).

If you need to use separate methods for Windows XP and Windows 7 machines for this user based method, then you will need two policies, one for Windows XP and one for Windows 7. Each policy will then need a WMI filter applied to filter the right policy to the right machines.

Applies to:

• Windows XP systems on a domain network.

Using a Reliable Time Source

A reliable time source is especially important if you use Windows Servers with Active Directory (AD). All servers and systems in an AD environment should be running on exactly the same time.

We recommend that you use an internet time source on your first Domain Controller, otherwise known as the PDC emulator. You can also use this setting on additional domain controllers.

Sections in this article:

• How To Configure Time Services to Use an Internet Time Server
• How to Configure Time Services to Use Domain Controller Time
• How To Check the Time Server Settings
• Troubleshooting Steps
• How to Turn off Virtual Machine Host Time Integration / Synchronisation Under Hyper-V

How To Configure Time Services to Use an Internet Time Server

Run the following command from an Administrative command prompt, on your Domain Controller(s).

net stop w32time

w32tm /config /syncfromflags:manual /manualpeerlist:"0.uk.pool.ntp.org 1.uk.pool.ntp.org"

w32tm /config /reliable:yes

net start w32time

w32tm /resync

How to Configure Time Services to Use Domain Controller Time

PCs and member servers in a domain should automatically use time from domain controllers. If they do not, and appear to be using time.windows.com or other default time settings, use the commands below.

net stop w32time
w32tm /config /syncfromflags:DOMHIER
net start w32time
w32tm /resync /nowait

How To Check the Time Server Settings

Use the following commands:

w32tm /query /configuration - This enables you to see what NTP settings you are using.

w32tm /query /status - This enables you to see the current performance of the time service, including its connection to the NTP server.

Troubleshooting Steps

If the w32tm /resync command faults, or the w32tm /query /status shows that the system is still using a CMOS clock, then the NTP server is likely blocked.

Steps:

• Trying pinging the NTP server, if it is a hostname, and make sure it resolves to an IP Address. For example, pinging 0.uk.pool.ntp.org should resolve to an address such as 185.53.93.157. Note that a reply is not necessarily expected, but your DNS system must be able to resolve the hostname to an IP address.
• Try using your Internet Service Providers (ISP) own NTP server. Some ISPs block access to NTP servers other than their own.
• Check that your Proxy Server and/or firewall are not blocking NTP. For NTP to work, UDP port 123 must be unblocked.
• Try configuring your Proxy Server or Firewall to use the same NTP time source. If this works, the problem is between your Windows Server and the Proxy Server or Firewall. If it doesn't work, the problem is further upstream.

How to Turn off Virtual Machine Host Time Integration / Synchronisation Under Hyper-V

Untick the Time Synchronisation option under Integration Services, in the virtual machines settings.

Applies to:

• Windows Server 2008 or newer.