Chat with us, powered by LiveChat

Windows 7 clients automatically rebooting for updates – no notifcation – WSUS

Wednesday, 27 April 2016

Windows 7 clients automatically rebooting for updates – no notifcation – WSUS

Recently I had a call from a client saying that they’re having computers randomly reboot (without warning) to install Windows Updates.  All machines were Windows 7, and they were all on the client’s domain.  They had WSUS installed and configured, with GPOs to define the backup settings etc.  In this case, the GPO stated that machines will automatically download and install updates at 4pm each day, and only reboot if there was no active user.

After checking the GPO, I was confident that the issue was not related to that, as it clearly stated that the computers won’t be rebooting automatically.  I remoted into the workstations to ensure that they’re actually applying the GPO (gpresult /r), which they were.  So it wasn’t GPO, and it wasn’t the workstations as far as I could tell.

I logged into WSUS itself, and checked the automatic approval settings.  That was all setup and was approving certain updates (such as Critical Updates and Security Updates etc).  When looking further down the Automatic Approval rules, I noticed that there had been a deadline set for installing the updates.

The deadline had been set for 5am on the same day that the Windows Updates were approved.  This means that the when a workstation turns on in the morning (which is usually after 5am…), it will realise that it has some updates available.  Because it’s already past the deadline, the workstations starts installing the updates as soon as it can, and applying them immediately.
The WSUS settings here overwrite the GPO settings, so even though it may have been defined in the GPO to not reboot, the computer knows that it’s already past it’s deadline to have these updates installed, so it ignores the remainder of the settings, and applies the updates straight away.  If the updates require a reboot, it will do the reboot immediately as well.  This was what was causing the ‘random’ rebooting of computers throughout the day.
To resolve this issue, one could change the deadline to perhaps allow a couple of days after the update has been approved, or in my case, completely remove the deadline requirement.  The GPO will get machines to install updates each day anyway, so it’s not needed in this case.
Wednesday, 20 April 2016

Increase Package Size – WSUS

Recently I was looking at an application called CSI, which ties into WSUS, and releases packages through WSUS for 3rd party applications (such as Java etc).  This is a really good way to ensure that all applications are kept up to date, and managed through existing WSUS infrastructure.

I noticed that some packages were larger than the WSUS limit of 384mb.  This is obviously a problem, as WSUS wouldn’t be able to package and push this out.  In order to get around this, I’ve had to tell WSUS that the package size can be larger than that.

The following Power Shell commands will get this job done:

  • Import-Module UpdateServices
  • [reflection.assembly]::LoadWithPartialName
  • (“Microsoft.UpdateServices.Administration”) | out-null
  • $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
  • $serverconfig = $wsus.getConfiguration()
  • $serverconfig.LocalPublishingMaxCabSize = 1024
  • $serverconfig.Save($FALSE)
In these commands, the 1024 is the newly updated maximum package size.
Note: WSUS cannot go larger than 2048mb, so don’t set the size to above that.
Friday, 15 April 2016

Define Start Screen Layout – Server 2012 R2 – Remote Desktop Services

Whilst setting up RDS Session Hosts today, I wanted to define the Start Menu layout for all users who will be logging in.

This TechNet article is rather handy for steps on how to export your start menu config, and then set it up under local group policy for all staff:

https://technet.microsoft.com/en-us/library/dn467928.aspx

Friday, 15 April 2016

Specify RDS Licensing Server from Session Host – 2012 R2

Earlier today I was setting up two new Session Hosts for a client, where we were creating a new collection.  Setting up the first one worked fine, but when logging into the second one, I noticed a message saying that there was no licenses for this server (for RDS) and it will stop working after 119 days.  Obviously there were licenses on the Licensing server, but for some reason this server couldn’t communicate to it to find out.

When checking the RD Licensing Diagnoser, it confirmed that there was no licensing server linked to this Session Host.  I had a look online for a way to set this up using the GUI (on either the RDS Gateway/Licensing Server, or the Session Host, but couldn’t find anything.

It’s a nice and simple command (there’s actually two of them) that is done through PowerShell to get it all working.  The command is the following:

Command #1
$obj = gwmi -namespace “Root/CIMV2/TerminalServices” Win32_TerminalServiceSetting

Command #2

$obj.GetSpecifiedLicenseServerList(“license.contoso.com”)

License” is the name of the RDS License Server in the environment.

After doing this, all I had to do was refresh the RD Licensing Diagnoser, and it accurately reflected the licensing server, and the amount of licenses I had etc.

Wednesday, 13 April 2016

Backup Exec causing Hyper-V checkpoint build up

Recently when deploying a new network for a client, we installed Backup Exec 15 to run backups of their Virtual Machines from Hyper-V.  The backups were working fine, but I noticed that for one VM, there was an excessive amount of checkpoints created, around the time that BE backs up each night.

If you have a look at the type of checkpoint, you will notice these are ‘recovery’ checkpoints, and can’t simply be deleted (.AVHDX files).
This creates problems when you’re wanting to edit the Virtual Machine settings (especially the hard drives of the Virtual Machine), as it will say there’s a checkpoint associated with the machine and you can’t edit it.  In my case, I was wanting to expand the File Server’s storage, but wasn’t able to until I sorted out the checkpoints.
The other VMs has the same problem (recovery checkpoints showing up), but there was only one per VM.  After looking online, and having to log a support call with Backup Exec, they informed me that this is a feature bug of Service Pack 3.  The following link shows their support article:
This article explains that you need to change the backup setting from ‘Faster Processing Method’, to ‘Standard Processing Method’.  After doing this, and running a new backup (confirming that it worked etc), I was able to run the PowerShell commands to remove the additional checkpoints.
Get-VMSnapshot -VMName ‘VMName’ -ComputerName ‘HOST’ -SnapshotType Recovery | Remove- VMSnapshot
 
 

This command worked well for all the VMs, except APFP01, which had the multiple checkpoints.  I got the following error message when I ran that command:

CATASTROPHIC FAILURE! – It’s not actually too bad.  It just means that you’re not going to be able to automatically remove and merge with the command that I had mentioned above.  To fix this issue, we’re going to have to manually merge each .avhdx file.  Firstly let me note that you will have to power down the virtual server before doing this.  To do this, you have to go into the location of the Virtual Machines, and find the .vhdx and .avhdx.  You need to find the newest .avhdx file, and rename the file extension to .vhdx (remove the ‘a’).  Once you’ve done that, click on Edit Disk in Hyper-V, find the .vhdx that you’ve just renamed, click Merge, then click Merge with Parent.  This will take a while depending on the amount of data that you’ve got.  Once that has finished, find the next newest .avhdx file, and rename etc.  Repeat the same process and merge with parent disk.  Keep doing this until you’ve merged all the .avhdx files, and you’re just left with your original .vhdx file.
Now once you have done this, you’re still going to have the checkpoints showing up in Hyper-V.  I haven’t been able to remove these checkpoints from Hyper-V using any of the commands used within that Backup Exec KB article.  To get the server back up and running, you will need to create a new Virtual Machine, and just set the drives to the existing .vhdx files.  Once you boot up, this will run exactly the same as the previous server.  You can then delete the old, problematic VM from Hyper-V.  Just keep in mind that the Virtual Disks you’re using are still in the old folder, so don’t delete the folder from Hyper-V.
Something that I came across when I was doing this, was that the second drive didn’t attach to the server fully.  It showed the C: drive and booted without problem etc, but the E: drive was missing.  I just had to go into Disk Management and set the disk to Online, as it was offline for some reason.
After doing all of this, I have been able to expand the drives without issue, and there have been no further checkpoints created from Backup Exec (after changing that setting).
Sunday, 10 April 2016

Windows 10 Start Menu not responding

Whilst at a client’s office rolling out new infrastructure, I noticed that logging into all W10 machines caused some issues with the Start Menu.  Clicking on the Start Menu simply wouldn’t do anything.  You could right-click on it without issue, but normal click did nothing.

This started to happen to all computers for all accounts.  I’d confirmed that everything was working well previously, so I started to look into whether it could be a new GPO rolled out or something like that.  Not being able to pin point any GPO which could have caused the issue, I started to investigate why the Start Menu wasn’t  working.  Checking Event Logs, it showed that items were trying to register with the Firewall, but failing.

I checked the Services and the Windows Firewall service had actually been disabled.  After enabling this again, and starting it up, everything started to work.  It turns out a technician had gone through each computer and disabled the Windows Firewall service for some reason!

So if anyone has this issue with the W10 start menu, the first thing to check should be the Windows Firewall service!

Sunday, 10 April 2016

Poor SMB performance on new File Server (2012 R2)

Recently upon setting up a new server environment for a client, I noticed that workstations had rather poor performance when accessing data from an SMB on the File and Print server.  Transferring of data to the file server was rather slow, and opening up .exes from the network took ~50 seconds  before I was prompted to run the application (not acceptable).  All servers were Server 2012 R2, and it was running on a Dell R430 with Hyper-V.  All the NICs are Broadcom, and the drivers were fully up to date.

After looking into this issue, I discovered that some settings on the Network Adapters needed to be changed.  When checking the properties of the network adapter (in this case I had two NICs in a team, so I had to do it on both of them), go to Advanced, and set the following items to Disabled:

  • Large Send Offload V2 (IPv4)
  • Large Send Offload V2 (IPv6)
  • TCP/UDP Checksum Offload (IPv4)
  • TCP/UDP Checksum Offload (IPv6)
  • Virtual Machine Queues
Keep in mind that when doing this,  it will drop off the network adapter for about 10 seconds.  If you’re doing this on a live Virtual Host, make sure you only  do it to one adapter, and wait for the adapter to come  back up online, and ensure the NIC Team is fully active again before performing this on the second NIC.  This will ensure you don’t lose network connectivity to the host, and subsequently to the Virtual Machines.
After doing this for both NICs, I tested netowrk connectivity, and it was considerably faster.  Even just loading the file structure on a network drive was immediate, rather than a 1-2 second wait.  Testing it out on the same .exe that I had issues with before, it’s gone from opening in ~50 seconds, to opening in ~1-2 seconds.
Saturday, 09 April 2016

Exchange 2016 ECP Blank After Login

Recently I tried to log into an Exchange 2016 console, but after actually typing in my username and password,  it gave a blank screen:

This happened when accessing ECP (or OWA) from the Exchange server, any other machine on the network, or even accessing it externally.  Upon looking into this, I realised that there was no self-signed certificate for the Exchange server for some reason.  There was an SSL cert, but no self-signed cert.  This needs to be created, and added to the binding of the ‘Back End’ website within IIS.

Once this was created, and added back into IIS, and the bindings were set, ECP and OWA started to work again.

Friday, 01 April 2016

File Permissions for Specific Security Group – Power Shell Script

Recently I have needed to run a report to get a list of all files and folders on a particular drive, and the security groups that have permissions assigned to those files/folders.  Upon looking into whether this was actually possible, I created a script to export a list of folders and their associated security group access.

Get-ChildItem C:\Users -recurse | ForEach-Object {Get-ACL $_.FullName} | select psPath,psParentPath,psChildName,AccessToString | Export-CSV -NoTypeInformation C:\TestExportFile.csv

This command will create a CSV file which we can use to then filter down, and get a list of all the folders that reference a particular group.  In this case, I have filtered the AccessToString field, which shows the security groups, and have searched for Testing Group 1 which was my test group.

This then shows only the folder locations which use the Testing Group 1 security group as NTFS permissions.  Although this is a rather manual process, it allows you to find all folders which use that particular security group.  This will come in handy if you’re wanting to delete a security group, and want to quickly reference a File Server to ensure that nothing is referring to that particular group.