Reset SA Password - SQL Server

I recently needed to get into an SQL database, which only had the SA account as a 'sysadmin'.  The unfortunate thing was the client didn't have the SA password documented anywhere.  So we needed to reset that password somehow, or risk having to completely reinstall SQL!

Luckily, there's a relatively easy way to be able to get into a locked out SQL database, by resetting the SA password.  The only caveat, is that you are a local administrator of the SQL server itself.  Most of the time it's going to be on the domain, so as long as you have a Domain Admin account, you're going to be able to get in rather easily.

Fisrtly, you will need to download PsExec.  It's from the Microsoft website.  Extract the contents to your desktop of the server or somewhere you can easily access the .exes within it.

Through CMD, navigate to the location of the EXEs.

psexec -s -i "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

This will fire up SQL Management Studio, running as the system account.  Once you've done that, go into the security section of SQL and reset the password for the SA account!

It's that simple!  Shouldn't take you more than 5 minutes to get in and reset the password, provided you come across this blog ;-)

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 T440 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.

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:

https://www.veritas.com/support/en_US/article.000100786

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).  

WSUS Fails to Connect

Recently I had a WSUS server which had to be rebooted.  Upon restarting the server, I noticed that I could no longer get into the WSUS console.  When trying to connect I was receiving the following error message:

Checking the Event Logs, I found two events which showed the following:

My next step was to check the health of WSUS with the following command:

WsusUtil.exe checkhealth
This was run from "C:\Program Files\Update Services\Tools" directory

Running this command gave me the following result:

Upon looking into this further, I noticed that there was a Windows Update which has caused some issues in the past for some people.  The update is KB3159706.  I checked my server and I did not  have this update installed, but thought I would humour it and try the fix anyway.  The fix mentioned in the KB article actually resolved the issue.  I did the following to get it back up and running:

1. Install the HTTP Activation role under .NET Framework 4.5 Features through Server Manager.

2. Restart the WSUS service

Yep...it was that easy!  After doing that, adding the WSUS server back into the MMC console worked fine and everything was back up and running again.

TFTP Open Timeout - PXE Boot | SCCM 2012 R2

Recently I was setting up PXE booting with SCCM 2012 R2 (new setup).  When starting the client workstation up and pressing F12 to network boot, I got the following error:

Having a look online to find out what this issue was, I struggled to find the exact cause of my particular issue.  There were many blogs and posts about this issue, but nothing referred to a solution which would have helped me.

It turns out that this is a bug with Microsoft and there is a Hot Fix available to download.  The Hot Fix is available here.

After installing this Hot Fix, I rebooted the SCCM server, then attempted to boot to PXE again on the client workstation.  This time it worked perfectly!

Issues Updating Print Drivers | KB3170455

Recently a client of mine updated their print drivers on the Print Server (through Print Managemnet).  Users suddenly had issues printing, where Word would say "Driver Update Required".  When a user would go to right-click on the printer and click on "Update Driver", they would get essentially a UAC prompt asking whether they trust that particular printer:

When they click Install Driver, it looks like it's installing and then it just falls back to the same message.  It looks like there's an endless loop where users can't print because of the driver update requirement, but they can't install the driver either.

These printers are deployed through Print Management and are deployed via GPO.  There are Point and Print restriction policies in place as well to remove any warnings or UAC prompts for installing new drivers, or updating drivers:

In theory, this should mean that there's no warnings and the drivers should just update.  I've had a look on the workstations and they're applying the policy correctly and the changes are there, so it's not an issue with applying the actual GPO.  With this in mind though, the warnings are still showing up and the drivers can't be updated.

When running the troubleshooter, it asks whether you want to install the updates with elevated privileges.  When doing this, it works fine.  After a lot of troubleshooting, this ticket was actually escalated to Microsoft support to look into this.  

They confirmed the following:

There was a Windows Security Update recently released which targeted the security of printing.  This was KB3170455 and this was the culprit!  Essentially what this update does is require drivers to meet certain criteria before they can be used.  The criteria is the following:

• Package aware
• Digitally signed
• Catalogue print drivers

Apparently the official drivers we had downloaded from the Canon website did not meet this criteria.  Uninstalling this update has resolved the issue for all users.  

At the time of writing this blog, there is no official word from Microsoft acknowledging the issue caused by their security update other than what the support technician has told me, but they have confirmed that since the update, there have been a large number of support calls raised to their help-desk.

There's currently only two options to get around this:

1. Download another driver that meets the criteria
2. Remove the Windows Security Update from all servers and workstations

Note: if you are a small enough company, you can work around this by installing the driver update with elevated privileges.

Operating System Deployment (OSD) with USMT Task Sequence Guide | SCCM 2012 R2

I have recently been setting up User State Migration as part of Operating System Deployment through SCCM 2012 R2.  What this will allow, is the re-installation of an Operating System whilst saving the user's locally saved data, such as data on Desktop, My Docs, background picture etc.  You can even go as far as to allow users to initial their own OS Refresh if they were having problems on their workstation.  It's a very good way in reducing IT Support overheads if you've got a stable SOE image.

The reason for this blog post however, is that USMT and OSD is a pain to get working well, and there's not a lot of information out there that specifically shows you how the Tasks Sequences should be configured.  After two days of playing around with SCCM trying to get this all working, 1,000,000 log files and a lot of Googling, I managed to get everything resolved and have got a stable Task Sequence running to refresh the Operating System.

Below are the requirements you will need to not only Build and Capture your image, but then also create the Task Sequence to refresh your OS with USMT.

Build and Capture
When setting up OSD and using USMT, it is critical that you correctly Build and Capture an image.  What I mean by this is that if you use the B&C Task Sequence and don't correctly set it up (it doesn't just work natively), you will have issues down the line with the second Task Sequence.

Once you have gone through the process of creating the Build and Capture task sequence, go to edit it and make the following changes:

Partition Disk 0 - BIOS

Partition Disk 0 - UEFI

Preserve Drive Letter - False

Apply Operating System

Select the Windows 7 Professional Image (or whatever one you're wanting to install), then select Logical drive letter stored in a variable, and type in System

Once you've done this, you will be able to run the Build and Capture task sequence.  Make sure it's saved to a location that computers will have access to.  This will be used when you're creating your OSD with USMT task sequence.

Operating System Deployment with USMT Task Sequence
This is the main Task Sequence for copying the user's local data, refreshing the Operating System, then copying the local data back.  This will usually be accessed from the Software Center within the Windows Operating System of the user's computer.

There's not too many settings you will need to change here, but if you don't get this right, it will cause hours of grief and Googling to try and work out why it's failing.

Partition Disk 0 - BIOS

Partition Disk 0 - UEFI

Preserve Drive Letter - False

Apply Operating System
Select the "2-2" image that you would have created within the Build and Capture sequence.  Then select Logical drive letter stored in a variable and type in System

Setup Windows and ConfigMgr
Make sure you add the highlighted section below.  This is not automatically added in.  This will be the FQDN of your SCCM server.

That's it!  If you've made sure that security permissions are set correctly (NTFS) on the SCCM server where USMT data will be stored and where data will be referenced, you will find that OSD will work smoothly and there shouldn't be any errors with your setup.

Failed to Run Task Sequence | 0X8004005 | SCCM 2012 R2

When running a Task Sequence through SCCM on a workstation, you may run into the following error message:

Whilst there could be other reasons that you're getting this error message, the first thing you should do is to check your BIOS Clock.  Make sure this is accurate, reboot and then run the Task Sequence again.

A lot of times you will find that this resolves the issue.

Intel SCS Task Sequences not working with SCCM 2012 R2 | Intel AMT: Configuration

This post follows on from my previous post which was about running a Task Sequence for Intel AMT: Discovery.  This post is in relation to the next Task Sequence in the list, which is called Intel AMT: Configuration.

This Task Sequence has the following details within SCCM:

Essentially the %% details are taken from within the Configure.bat script.  Running the TS isn't a problem, but it is deciding to fail when after it's downloaded the required data:

Surprise surprise!  I guess it wouldn't be SCCM if there wasn't issues!  Now the fun part of finding out why it's failing!  I had a look at the event logs on the workstation that I was running this TS on and I came across this event:

So we've got a few errors here.  TCP Error, Caller is unauthorised, Valid password not found.  From here I checked the SMSTS.log files to see what was happening.  The logs were about 41 pages long, so I'm not going to copy it all here, but there were various errors within this:

<![LOG[Failed to run the action: Intel AMT: Configuration. 
The process cannot access the file because another process has locked a portion of the file. (Error: 00000021; Source: Windows)]LOG]!><time="15:10:04.029-480" date="07-14-2016" component="TSManager" context="" type="3" thread="2724" file="instruction.cxx:895">

I had a look at the Configuration.bat file that the Task Sequence was calling and made a few changes to the contents:

I also ensured that the following contents had been edited so it was showing the correct SCCM server, and site:

Once I had done this, I ran the batch file again from the local workstation (instead of running it through Software Center) so I could see how it was running, and whether there were any error messages etc.  This time it progressed a lot further than before.  I don't have a screenshot of the error message that I was getting this time, but it was essentially connecting to the AMT device and then erroring out saying that the password was incorrect. 

Looking into the setup of the whole script/software, it looks like Intel SCS and Intel AMT: Configure relies on AMT not being configured on the local device.  What had happened was this device had been setup with MEBx (which is essentially the AMT login through BIOS) where it forces you to reset the password.  When this script was trying to connect to the device, it was using the default "admin" password which was incorrect as it had been changed.  This is why it was failing. 

The only way to get around this was to take out the CMOS battery to completely reset the BIOS and MEBx.  After doing this, I confirmed that the "admin" password was back in, not the custom password we had originally configured.  When running the script now through Software Center, it works!!

After doing this, I was able to Discover AMT Status through SCCM:

Once that was complete, it now showed me that the device had been externally provisioned!  

We can now control the device through SCCM:

Part 1 - Intel AMT: Discovery

Intel SCS Task Sequences not working with SCCM 2012 R2 | Intel AMT: Discovery

Recently I have been labbing a new setup with SCCM 2012 R2 with Intel SCS.  The idea was to get Out of Band Management working with SCCM for some workstations which had Intel AMT.  I followed this guide, which was very helpful in getting everything setup.  The only difference was that I was using the latest version of Intel SCS 11.0 rather than version 9.0.  When I ran into some issues (and let's face it, you always run into issues when using SCCM), I noticed that there was literally nothing online with regard to the issue I was having...so here it is!

The problem I hit was when I was enabling the various Task Sequences to run discovery and configuration of the workstations for Intel AMT.  The first task sequence works fine, which is Intel SCS Platform Discovery.  The second task sequence however; Intel AMT Discovery fails when I try to run it.  I'm not really able to find out what is going on through the logs, as you know with SCCM, it's almost impossible to find anything as there's like 1,000,000 logs to sift through.

Looking into the Task Sequence, all it does it call up a batch file called Discover.bat.  I ran this script manually, adding a pause command at the end so I could see what was going on.  I noticed the following errors:

So it looks like there's nothing wrong with SCCM, and there's potentially nothing wrong with the batch script.  The issue looks to be certificate related.  Great!

Looking at the batch file, it calls an Executable file to run.  I opened this file up (right-click, Properties), then checked the Digital Signatures of the file:

As you can see, there's a lot of intermediary certificates that are required.  I only had the Root CA certificate installed.  I went through that list and installed each certificate, then ran the Task Sequence again from Software Center (through SCCM).  This time it was successful.  In future, we will need to ensure that these certificates are exported and then deployed to all computers within the network.

Part 2 - Intel AMT: Configuration

Remote Desktop licensing mode is not configured

Recently when I was on a client's server, I noticed a message popping up saying that Remote Desktop licensing mode was not configured.

When looking at the RD Licensing Diagnoser, it showed the following details:

The warning says "The licensing mode for the Remote Desktop Session HOst server is not configured".  Down the bottom of the screen, you can also see "The Remote Desktop Session Host server is not configured with any license server".

To fix this problem you will need to run two PowerShell commands to ensure that the server is targeting the correct licensing server.  The commands are the following:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

$obj. SetSpecifiedLicenseServerList("licserver.domain.local")

Change the last section to ensure that the FQDN of the licensing server has been added in.  Once you've done that final command, you should see the following:

The final step once this is done is to change a registry entry.  Changing this registry entry will manually set the licensing mode of the server.  Open up Regedit and go to the following location:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core\LicensingMode

LicensingMode is a DWORD which will need to have it's value changed.  Your options are below:

2 - Per Device
4 - Per User

I changed mine to '4' as I wanted it to be licensed 'per user'.  

Once you've done that, simply reboot the server and you should no longer have this problem.

File Server Resource Manager (FSRM) showing inaccurate quota usage

Recently a client of mine came to me saying that File Server Resource Manager (FSRM) Quotas wasn't reporting accurately.  On this particular network, Folder Redirection had been enabled and all data was being redirected back to the file server.  There was a 250MB quota setup for each user's redirected folder (ie Desktops has 250MB limit).

FSRM Quotas was showing that a particular user's Desktop folder was using 160% of the quota limit.

When checking how much data is actually being used in that folder through FSRM, it shows the following:

When checking the file location, it's also showing that the folder is empty.  I ensured that Hidden Folders were being shown.

Checking the 'Size on Disk', it definitely gave the same file size of 401mb, so I knew that there's definitely something within that folder that's not being shown to me.  I checked the view settings of the folder and had to un-tick the following item:

With that un-ticked, I was now able to see the Recycle Bin within the user's folder:

So now we have worked out why FSRM is showing what it's showing, we need to remove all the Recycle Bin files from each user's Folder Redirection location.  This was relatively easy, and I did it with a batch script, which had the following in it:

for /d %%i in (E:\Users\FolderRedirection\Desktops\*) do @ rd /q/s "%%i\$Recycle.Bin

for /d %%i in (E:\Users\FolderRedirection\Documents\*) do @ rd /q/s "%%i\$Recycle.Bin

for /d %%i in (E:\Users\FolderRedirection\Pictures\*) do @ rd /q/s "%%i\$Recycle.Bin

for /d %%i in (E:\Users\FolderRedirection\Music\*) do @ rd /q/s "%%i\$Recycle.Bin

for /d %%i in (E:\Users\FolderRedirection\Videos\*) do @ rd /q/s "%%i\$Recycle.Bin

pause

Running this script goes through all the usernames and then removes all the $Recycle.Bin files within the specific folders.  You will need to adjust the location to ensure that it's targeting the correct folders within your network. 

Microsoft Exchange could not discover any route to connector CN=Windows SBS Company Web Connector [SERVERNAME]

Recently when I was troubleshooting some Exchange issues on a client's server, I noticed the following Event log and thought I would troubleshoot it further:

What's happening is that a 'Foreign Connector' is still present in the Active Directory and Exchange configuration for an old SBS environment (SBS was recently decommissioned).  This is for SharePoint email to web feature, which was never used and it's not needed.

To get rid of this, it's safe to just delete the connector.  To find the connector, type the following:

Get-ForeignConnector | fl

To delete the connector, type the following:

Remote-ForeignConnector "Windows SBS Company Web Connector SERVERNAME"

This will remove the orphaned connector, clean up the errors and stop them from occurring.