Frequently Asked Questions (FAQ)
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:
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
Note: The commands above tell Windows to use two public NTP time servers from ntp.org. Your internet service provider may have their own NTP servers and may prefer that you use those. Use the w32tm /resync command to make sure the new settings are work - ensure that you get a message that this completed successfully.
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 /update
w32tm /resync /nowait
net start w32time
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.
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.
- 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 18.104.22.168. 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.
Untick the Time Synchronisation option under Integration Services, in the virtual machines settings.
- Windows Server 2008 or newer.
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.
Note: If you have multiple users sharing the same profile, this is likely a mandatory profile and not a roaming profile. You should not need to delete a mandatory profile and should seek further advice if you are experiencing profile corruption.
- 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.
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.
- 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.
- Domain networks with Roaming profiles and redirected folders.
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:
- 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.
- 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.
- Open the Hyper-V Management Console
- Click on each virtual machine, checking the Integration Services status in the Summary tab
Note: Upgrading the Integration Services inside a virtual machine requires that the virtual machine is rebooted afterwards. This means that you need to plan for downtime or a maintenance window for each virtual machine.
- 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.
- When the virtual machine has rebooted, the Summary tab should now show that Integration Services are up to date.
- 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.
Recommendation: Always test network changes on a small group of machines before deploying the improvement. Where possible, implement the change room by room or department for department and monitor the situation for any unexpected side effects.
- 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.
- 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.
- Networks running Windows Server with Windows clients.
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.
Reminder: The Group Policy Preferences client is an optional extra for Windows XP SP2 and Windows XP SP3. If this client is not installed on Windows XP all Group Policy preferences are automatically ignored.
- 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.
Note: Always test Policy changes against a test OU and a test user account first. When confident that the setting is working as desired, then gradually roll out the change, ensuring that you test that the setting is working as desired with no detrimental effects.
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.
- Windows XP systems on a domain network.
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.
Note: This solution has not been tested on Windows 8 / Windows 8.1
- Desktop systems running Microsoft Windows 7 as part of a domain network.
- 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.
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.
Internal Server name: exchange.local
Webmail address: http://webmail.company.net/owa
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.
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.
- 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
Tip: You can use the "get" version of the commands, for example get-ClientAccessServer -Identity exchange to see what the current setting is, and make a note of it first.
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
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.
- Outlook 2007 and Exchange 2007 or Exchange 2010
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."
On the screen with the error message above try the following steps:
- Hold down "Shift + F10" to open the command prompt
- On the command prompt type "regedit" with no quotes to open the Registry Editor
- Go to:- HKLocal machine -> System ->Setup ->Status -> ChildCompletion
- Highlight ChildCompletion and on the right you will see "setup.exe"
- Double click "setup.exe" and verify the value is set to "1"
- Change the value to "3"
- Close the registry editor and close the command prompt.
- Click OK on the error message and now the installation process should complete.
- Deployments of Windows 7 using SCCM 2012.
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.
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.
Note: This problem does not apply to user login scripts defined on the users active directory account Profile tab.
- Products running Windows 8.1 / Windows Server 2012