Tag Archives: fixed

SQL, dbatools and Webroot

I have been busy working on a SQL server migration, and have come across a couple of issues.

Firstly, attempting to install or upgrade an SQL instance with Webroot on the machine generates an unauthorized action on the machine. Reviewing the error logs provides the following error

Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException
Message: 
Attempted to perform an unauthorized operation.
HResult : 0x84bb0001
FacilityCode : 1211 (4bb)
ErrorCode : 1 (0001)
Data: 
WatsonData = [email protected]{145996FC-8E6B-47AB-BEA5-A84F12B72AF5}

Navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry shows the value {14599…..} is Webroot. Set server into unmanaged mode and then removing Webroot then enabled me to install SQL service packs.

I’ve also run into the same issue on new installs which leads me to the second issue.

I’m using dbatools to install with notes taken from the newly printed dbatools in a month of lunches. A book I purchased pre-pandemic and promptly forgot about but I finally got my hands on the book.

dbatools is a fantastic resource for SQL admins who want to automate everything and a common task is installing SQL.

Unfortunately there’s a typo in Listing 13.6 and 13.7 The parameter SQLUSERDBDATADIR that is coded into the sql config.ini file should actually be SQLUSERDBDIR

It took me a while to figure that one out. I then went to check out the books online only to find someone had found and reported the same error – yesterday!

The moral of the story is to check the books online first.

Also, whilst looking at my Manning books – I have a Powershell problem (or maybe with all these books I don’t!

Listing of Powershell books from Manning Publications

Fixed: 161008 The source virtual machine doesn’t have a network interface or all the network interfaces were deleted when using Azure Migrate

I’ve been working on an Azure Migrate project at work this week and had an interesting issue after attempting to start a replication of the source servers. The configurations were brought in from the Azure Migrate assessment tool but I received an odd error that there was no connected network interface on the source server.

This is a very strange error as all the source servers do have network interfaces otherwise there would not be much point in migrating them up to Azure! The error id 161008 and messages of “No connected network interface is configured for the virtual machine” and “The source virtual machine doesn’t have a network interface or all the network interfaces were deleted” did not make much sense, however the recommendation of “If there is no network interface on the source machine, add one and then go to Computer and Network settings of the virtual machine to configure the network interface” was a slight clue.

error id 161008 and messages of No connected network interface is configured for the virtual machine" and The source virtual machine doesn't have a network interface or all the network interfaces were deleted

Part of the solution steps imply that you create a nic on the server, but as the server has not actually been created in Azure yet, this step is not possible and the source server obviously has nic’s already setup so no change can be made on that server.

After getting a second pair of eyes on the issue (Thanks A!) , we had an Aha moment in the Compute and Network section of the server setup. The Assessment had set the nic’s on the machine to Do not Create and Secondary Network. As there was no primary nic configured on this page, the error message above is generated. Setting the Secondary nic to Primary rather than Secondary enabled the replication to start successfully.

Screenshot of configuring Compute and Network for an Azure migrate server

2 lessons from this – Always ensure you have a primary nic configured when using Azure Migrate. Get a second pair of eyes for that fresh look at the problem as sometimes you just can’t see the wood for the trees.

Fixed: The Active Directory schema isn’t up-to-date, and this user account isn’t a member of the ‘Schema Admins’ and/or ‘Enterprise Admins’ groups.

Setting Primary Group to Schema Admins

Attempting to run an Exchange CU update on a server this morning and the server kept giving “The Active Directory schema isn’t up-to-date, and this user account isn’t a member of the ‘Schema Admins’ and/or ‘Enterprise Admins’ groups” error message when attempting to run setup.exe /Prepareschema /IacceptExchangeServerLicenseTerms as a pre-requisite installation step. My user account was a member of both of the groups but the error still occurred.

Changing the accounts primary group in Active Directory by selecting the Member Of tab and then selecting the Schema Admins group and selecting Set Primary Group, logging off and back on again led to the setup process completing successfully.

Don’t forget to set it back after the installation has completed.

Fixed: ScreenConnect / Control missing from Labtech / Automate

Automate screenshot

For the past two days my Automate window was missing all of the Screenconnect plugins that allow one click remote access to client machines. Both the one that shows at the top of the computer list and also when the machine window is launched. (Screenshot below shows how it should look)

Screenshot showing the control icon in Automate for computers

A reinstall of the software (including renaming the left over Labtech files in Program files and Program Data after removing the software) did not fix the issue.

However, reviewing the C:\ProgramData\LabTech Client\Logs\yyyymmdd_LTcErrors.txt showed lots of plugin exceptions including the following:-

An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information

Following that link provided the hint that loadFromRemoteSources needs to be enabled.

Editing “C:\Program Files (x86)\LabTech Client\LTClient.exe.config” and adding <loadFromRemoteSources enabled=”true”/> just before the /runtime> line, Automate now includes the control button.

LTClient config file showing the loadfromremotesources element

Fixed: Lastpass seems to randomly add incorrect data to Forms.

We use a web based documentation system at work and have had a couple of instances where data for companies (ie Company X) seems to have been randomly edited in forms to include data from another form (ie Company Y) in the system. In a form that had a username, password, url and notes field we discovered that a tech could go in and edit the notes (and only the notes field) and without realising it, the username and password were also being updated in the form. The tech would hit save and now the saved password was incorrect.
Thankfully the documentation system has revision histories to allow us to revert back to the previous settings. but it is still a painful process to go back and review recent changes to see which ones were genuine edits and which were changed incorrectly.

We initially blamed it on LastPass filling out data as the issue would not occur if we disabled LastPass, however a search in LastPass would not return the data that was being added to the form. It took us a while to track down, but Chris, one of our techs worked out what was going on.

Sample lastpass password screen with extra field button highlighted

LastPass has additional fields that don’t show up when you browse (and apparently search) and the data from these extra fields were automatically being filled in for some reason. Click the wrench, highlighted in the above screenshot to see the extra hidden fields.

Our solution was to delete these extra fields, save the record in LastPass and we no longer have LastPass corrupting our data.

Fixed: NPS using Azure AD not prompting for 2 factor on phone

Screenshot of Yubico numbers for 2FA verification

We were recently came across an issue with configuring the NPS (Network Policy Server) to use Azure AD’s 2FA authorization to validate VPN access to one of our clients. The initial configuration was fairly straightforward with the instructions at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension but after connecting to the VPN server, we were not getting the push notification to our phone for the final verification steps.

Going through the Network Policy Server logs in event viewer we saw an error message as follows ” NPS Extension for Azure MFA: CID: 341b704d-03f1-4ba6-ae92-eb19ae2f2bf3 :Exception in Authentication Ext for User myusername :: ErrorCode:: CID :341b704d-03f1-4ba6-ae92-eb19ae2f2bf3 ESTS_TOKEN_ERROR Msg:: Verify the client certificate is properly enrolled in Azure against your tenant and the server can access URL in Registry STS_URL. Error authenticating to eSTS: ErrorCode:: ESTS_TOKEN_ERROR Msg:: Error in retreiving token details from request handle: -895352831 AADSTS7000112: Application ‘981f26a1-7f43-403b-a875-f8b09b8cd720′(Azure Multi-Factor Auth Client) is disabled. “

The key was the last line – Azure Multi Factor Auth Client is disabled. Despite the fact that 2FA was already in use to verify access to the Office365 portal and desktop apps, it seems that the client was not enabled in Office365.

This was fixed by running the following in a powershell window connected to Azure AD..

Set-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” -AccountEnabled $True
Set-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” -AccountEnabled $True

This then enabled 2FA to work with NPS. I put in a PR request to the official documentation to have this as an official troubleshooting step but the PR was closed. Hopefully this post and the PR will help others in their configuration as it did seem to be a fairly common problem.

Fixed – Screenconnect blocked by Windows Smartscreen

Due to an expired code sign certificate, the version of Screenconnect that is launched from Connectwise Automate (aka Labtech) fails to run on 2 of my Windows 10 machines but works fine on the rest of the machines. The error message “Your administrator has blocked this application because it potentially poses a security risk to your computer”. The ones that fail are running Windows 1809 and 1903 so I suspect that there is some of the new features of SmartScreen are enabled and older versions do not have these settings.

Your administrator has blocked this application because it potentially poses a security risk to your computer

Checking out the file used for Screenconnect, I saw that the certificate used to sign the exe file expired on February 1st this year, but I’m not sure why my machines suddenly started to refuse to run it the last few days of March.

The Screenconnect.WindowsClient.exe is downloaded to a random subdirectory of appdata\local\apps\2.0 so I recommend you navigate to this directory and then search for *.exe and check the correct screenconnect file as per the screenshot below which shows the certificate expiring on the 1st February

ScreenConnect certificate expiry dates

After searching around and contacting Connectwise Support they advised me this would be fixed in an upcoming version. In the meantime setting the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\Security\TrustManager\PromptingLevel\Internet to a string type of Enabled will allow the ClickOnce application to popup and this allows the dialog box to give an option as to whether the file should be run or not (the previous setting was Disabled). This then allows the user to select yes to install and run the file overriding the invalid SSL certificate.

Obviously this is not a great idea but it does allow you to run Screenconnect from within the Automate window. (The other alternative is to use the Screenconnect website itself to connect).

Fixed: pihole -up gives “Could not update local repository”

I received a notification on my pihole web console that it needed an update and the process is usually simple – log into the server and run pihole -up

However, this time I received the error “Could not update local repository. Contact support” – not very helpful.

pihole -up gives a Could not update repository. Contact support error messageReading several articles it seems that any change to the pihole files means the local git repository can get out of sync with the master repository and therefore cannot be updated. I had installed the bandwidth test plugin so I suspect that was the issue. As this plugin didn’t work it was not a huge problem resetting back to a vanilla install.
There were several articles on the pihole site and piecing a few of them together I came up with the following solution.

  cd /var/www/html/admin
  sudo git fetch –tags
  sudo git reset –hard
This gave me the following error:-

fatal: Unable to create ‘/var/www/html/admin/.git/index.lock’: File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by ‘git commit’. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

Removed with the following

  cd .git
  sudo rm index.lock
Final update command and this time it completed successfully.

  pihole -up

This completes the install with 

Update Complete!

Current Pi-hole version is v4.2.2
Current AdminLTE version is v4.2
Current FTL version is v4.2.2

Fixed: Unmountable Boot Volume error with Windows Server 2016 and Storagecraft’s SPX

BSOD imageWe’ve been tracking down issues with Windows Server 2016 on a multitude of servers this week where the servers will reboot and come back with Unmountable Boot Volume which is a pretty nasty experience for oncall. So far we’ve mainly seen it on Domain Controllers but also on a Hyper-V server. The solution is typically to do a last known good boot on the machine and then try to work out what has changed on the server and needs redoing. So far we’ve had issues with duplicate servers in Webroot and Automate along with a couple of server functions not working correctly.

Initially we thought it was a problem with Windows Updates, but it seems that the culprit is Storagecraft’s SPX version 6.7.4
The solution is either to downgrade to version 6.5 or get a patch for 6.7.4 that fixes this issue.

Download location for SPX 6.5.2:

For 6.7.4, You will need to get the patched stcvsm.sys  from Storagecraft and then apply these instructions.

Patch is a very manual process. New version of the stcvsm.sys driver is 2.2.73.0.36
1. Install SPX 6.7.2:
2. Do NOT reboot
3. Rename %windir%\system32\drivers\stcvsm.sys to %windir%\system32\drivers\stcvsm-rtm.sys
4. Copy the 2.2.73 driver to %windir%\system32\drivers. Be sure to select the correct ‘bitness’.
5. Reboot

It’s been very frustrating to have gone through this issue without any notification of this pretty serious bug from #Storagecraft

Edit: Today I discovered that Storagecraft now have a more detailed knowledge base article about resolving Inaccessible Boot Device after upgrade to 6.7.x. Judging from the comments I’ve had here, I’m not the only one who has had this issue and it still keeps happening for some users.

Fixed: Office 2010 installation with MAK key gives Error: Can’t decode PIDKey – Invalid digits! ErrorCode: 0(0x0)

After doing an administrative installation of Office Professional Plus 2010 for a client, I was trying to test the installation of office on a desktop machine but kept getting “Error: Can’t decode PIDKey – Invalid digits! ErrorCode: 0(0x0).” as the error message. I confirmed that the key was correct by doing a manual installation of the software and using the same product key that was successful. I was unable to find any useful pages on the internet with this error message so ended up logging a call with Microsoft Product Support to troubleshoot the installation.

Our troubleshooting steps were to remove the updates folder completely and try an installation – this worked so we knew the problem was in the updates directory. Recopying back the files from the extracted service pack 1 dvd worked successfully so the problem was either service pack 2 or the setup.msp file. I copied back the sp2 files and again the software installed successfully (note that having a virtual test pc makes these tests very easy. No uninstalling of office required!)  Again the installation was successful. I then copied the setup.msp file back into the updates directory and the installation failed again. As the configurations that are made in the setup.msp can either be set in the config.xml or group policy it was ok to proceed without using the setup.msp.

Full details of the log files and more information can also be found at the Microsoft forums where I posted the initial request for help.