Blog

I was working with a customer who was upgrading all of their PCs from Windows 7 to Windows 10. Many of the existing programs were old, outdated, and incompatible with Windows 10.
 
One particular issue we had was installing their Digital Persona fingerprint scanner to work with the TIB website. It turns out that on HP devices that have HP Protect Tools, or any of the built in HP security software features, those must be uninstalled first before the fingerprint reader software will install.
 
I uninstalled Protect Tools, and tried to run the fingerprint scanner installer again, but received an error that HP Protect Tools was still installed. Research showed to rename certain folders in C:\programs and even to rename certain .dll files as well. Did all of that, and it still showed that Protect Tools was installed.
 
I called support for TIB since they were the ones that provided the initial troubleshooting steps, and it was their fingerprint scanner. They were unable to help beyond mentioning the .dll files to rename. I then called HP support to see if there were any particular registry keys that I might need to change to prevent the error. They said there were not any, and suggested that I would need to reinstall the OS to remove any of their preinstalled software. This was not a viable solution as I had spent hours already installing other software, and this was one of the last items remaining on our list of programs to install. I continued to research and one article suggested I would need to go to HP website and reinstall Protect Tools, and then uninstall it again.
 
I reinstalled Protect Tools and then went through the uninstall process again. This time I paid closer attention to the uninstaller. While the uninstaller is running, there are a few prompts that come up, asking for verification of uninstallation. One of those prompts is a little sneaky and turned out to be the culprit. It is a yes/no prompt and asks if you wish to proceed with uninstallation. It provides information about the uninstall, but if you keep reading, it says "Press Yes to save current settings and preserve data for future use, Press No to completely uninstall."  Those aren't the exact words, but something similar. I clicked No and after the Protect Tools uninstaller finished, the Digital Persona software installed without issues.

 

VMware Content Libraries are a 6.x "new" functionality (I use quotations because 6.x has been out for a while) that I've really grown to enjoy. Content Libraries allow you to store objects such as ISOs, templates, etc. in a central repository that can be shared with other vCenter environments. One of the biggest use-cases is to clear up all those random "ISOs" folders on various datastores as engineers, who are searching for an ISO, look in just the wrong folder first and create their own. 

When Content Libraries were first released, there were a few issues that made it difficult to use. The main issue was that in order to use an ISO in the library, I had to download it first, and then connect it to through the web client. For that matter, I may as well just continue to use the locally stored ISOs on my system anyway. You could still deploy templates from the library, which helped, but ISOs were what I really was looking forward to. 

vCenter 6.5 (and 6.7) fixed this and allowed you to connect ISO images directly from a Content Library. When I stood up our 6.5 cluster internally, I started setting this up and created a repository on a FreeNAS device with the share exposed via NFS so that I could use some cheaper storage to hold this content. Growing excited, I tried to create my first VM with an ISO image stored in the library. And it didn't work. Turns out, in order to connect an ISO from a Content Library, the backend storage must either be a VMFS datastore directly connected to the host so that the VM can "see" it. 

https://kb.vmware.com/s/article/2151380?lang=en_US


 

With our move to Nessus for our audit scanning, we are digging deeper into unsupported software. In these checks, there has been a software that has shown up across a majority of different customers which is unsupported Microsoft XML Parser and XML Core Services.
 
Microsoft XML Parser and XML Core Services are used to create and validate data in XML documents and have the ability to parse and process the data. More info can be found here: https://searchmicroservices.techtarget.com/definition/XML-Core-Services
 
One customer that I was working with had questions about the software because it was showing up as unsupported for a server that they just installed on the network. After doing some investigation, we found that the server did in fact have the unsupported Microsoft XML Parser and XML Core Services installed along with the current version of the software. After doing some additional research, it appears that when there is a new version of the software released, the update installs the new software, but does not remove the old unsupported software.
 
If the current version of the software is installed, then the unsupported versions can be removed manually.
 

 

I recently built a new VM with Windows Server 2016 and installed Exchange Server 2016. As part of hardening the server, I implemented our normal security header and cipher suite hardening steps. The Exchange Control Panel (ECP) appeared to function properly after these changes were implemented, but about a week later I found an issue where one of the less commonly used pages would not open. The page would not load the style sheets and you could not navigate to the page when using the FQDN from the local server. The page mostly worked when accessing it via https://localhost/ecp or from the FQDN outside the network.

During troubleshooting, I decided to remove the security headers to see if that would resolve the issue and it did. I determined that adding the X-Content-Type-Options security header broke some pages in ECP. The only option for X-Content-Type-Options is "nosniff", so there is no alternate value to set. Basically, the Exchange style sheets aren't specifying the content in the style sheets and "nosniffs" tells the browser not to guess the MIME types. I implemented all of the other common security headers, but did not implement X-Content-Type-Options.


 
 

I recently worked with two Outlook 2016 installs that had been working fine for months, then both experienced an issue when attempting to launch Outlook. They were 'randomly' getting one of the following errors:
 
Your mailbox has been temporarily moved to Microsoft Exchange server.
A temporary mailbox exists, but might not have all of your previous data.
You can connect to the temporary mailbox or work offline with all of your old data.
If you choose to work with your old data, you cannot send or receive e-mail messages.
 
'AD lookup for email address failed "0x800500d"'
 
When attempting to create a new mail profile for testing, the new profile would come up in the following format - outlook_[letters and numbers]@outlook.com
 
During this time, both Outlook Web Access and ActiveSync access were working properly, along with building a mail profile using Outlook 2010 or 2013. I later found out that both clients had their email address for AspireMail added as an alias to a Microsoft account. We considered removing the alias, but we eventually came across the following article: https://blog.skykick.com/new-microsoft-direct-connect-feature-may-prematurely-connect-outlook-to-office-365
 
Starting in Outlook 2016 version 16.0.6741.2017, Microsoft enabled a new feature called Direct Connect to Office 365. It was designed to quickly connect Outlook 2016 to Office 365.
 
However, if Microsoft's Autodiscover is not working on the source server or the connection between a computer and the source email server is interrupted, Direct Connect may cause Outlook to connect to Office 365 prior to cutover, even though the Autodiscover DNS path is still pointing to the source server.
 
Once we added the DWORD registry key ExcludeExplicitO365Endpoint Value : 1 to the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover, Outlook 2016 was then able to successfully authenticate the email account, finding the appropriate Autodiscovery DNS path.

 

The First Problem
After I installed Cisco Webex Teams, Skype began to crash each time I launched it.  I found some articles stating you can only have one application use Outlook for status updates and if you have both Webex Teams and Skype, it can cause Skype to crash (see https://collaborationhelp.cisco.com/article/en-us/gk4yog and https://collaborationhelp.cisco.com/article/en-us/yf1gc7).  My guess is this is what was causing Skype to crash.  However, it sounds like this issue didn't occur with others in our company so what was different with my install?  Well, my install was a little unique as I apparently already had a "personal" Webex account from when we used Webex years ago for webinars within our company.  With a personal account, you have options to integrate with Microsoft Outlook – my guess is one of these settings was enabled prior to "converting" to an enterprise account (with enterprise, these settings are not available).
 
The Solution to the First Problem
  1. First, I uninstalled Cisco Webex Teams.  After uninstalling Webex Teams, Skype would work fine, but if I reinstalled Webex Teams, Skype would crash again.
  2. Second, I tried installing Webex Teams and then running a "repair" on Outlook.  This seemed to fix the issue with Webex Teams and Skype (I could have both installed and Skype would not crash); however, this created my second problem – Outlook no longer showed "online status" or "presence" for company users (see internal staff status when I send emails in the "To" field).
The Second Problem
After running the repair on Outlook to fix the problem with Skype crashing when Webex Teams was installed, Outlook no longer display the "online status" or "presence" – while this doesn't seem like a critical issues, it has helped me ensure I don't send internal emails to customers with similar names in the past, so I wanted to get it fixed.
 
The Solution to the Second Problem
  1. First, I found the setting where you can enable online status (https://support.office.com/en-us/article/use-skype-with-outlook-to-display-a-contact-s-presence-information-b1509222-2c5d-4cd4-bff7-508d2b6f410d) but it was checked.
  2. Second, I researched the Registry settings for Skype and Cisco Webex Teams and found the following two settings I needed to change in order for Outlook to show "online status"
    1. Computer\HKEY_CURRENT_USER\Software\IM Provider
      1. Had to change the DefaultIMApp from "Cisco Spark" to "Lync"
    2. Computer\HKEY_CURRENT_USER\Software\IM Providers\Cisco Spark
      1. Had to change "UpAndRunning" from 2 to 0

 

Every time I would lock my Surface Pro running Windows 10 it would disconnect from the network after about a minute or two.  This would cause certain applications to disconnect and quit working.  After some research I found the culprit was an Advanced Power Setting called "Console lock display off timeout" which by default is disabled from view and set to 60 seconds.  To enable this setting, simply:
 
  1. To enable the "Console lock display off timeout" setting follow these steps:
    1. Open the Registry Editor (Press Windows key + R on your keyboard to open the Run command and type regedit and click ok)
    2. Browse to KEYLOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\7516b95f-f776-4464-8c53-06167f40cc99\8EC4B3A5-6868-48c2-BE75-4F3044BE88A7
    3. Double click on Attributes to open Edit DWORD Value and set the Value data to 2 and click ok
  1. Now that the "Console lock display off timeout" setting is enabled, you can set the value by following these steps:
    1. Open the Control Panel
    2. Click on Power Options
    3. Select Change plan settings
    4. Select Change advanced power settings
    5. Navigate to Display > Console lock display off timeout and set the timeout to whatever you want (in minutes)
    6. Note, you can also use the PowerCfg.exe utility to set the display timeout using the following commands:
      1. powercfg.exe /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOIDLE <time in seconds>
      2. powercfg.exe /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOCONLOCK <time in seconds>
      3. powercfg.exe /setactive SCHEME_CURRENT
  1. After going through this process, I also understand it may be possible to bypass the default screen timeout of 60 seconds following a locked system by setting the basic "Turn off the display" power setting to "Never"; however, this may not be ideal in many situations.
 It appears my surface docking station considered my surface asleep when the display was disabled after 60 seconds from when I would lock my system; therefore, the docking station disconnected causing my network connection to be lost.

 

When trying to use open WiFi such as in a hotel or airplane and you have to go through an authorization page, you can have trouble getting started if your default page is something like https://google.com that is using HSTS headers and doesn't offer an HTTP option. Many times, the intermediate authorization page doesn't show up because the browser won't redirect from your HTTPS home page.
 
If this causes problems, you can always try to go first to http://neverssl.com which is HTTP only and will usually allow the intermediate authorization page to come up and get you started. Then, once online, you can proceed to setup a VPN connection, etc.

 

For our audits, we run VMware Health Analyzer (VMHA) on any vCenters to collect information on ESXi build numbers, snapshots, dormant VMs, etc. Recently, a customer we were scanning had two vCenters, and while VMHA worked fine on one of them, we were getting errors on the other. Standard troubleshooting didn't work, and the customer didn't know why we weren't able to collect the information this year. After running nmap on the vCenter, we determined the customer had redefined the port used for this vCenter instance and simply defining the port in our scan credentials solved the issue.