Blog

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.


 

I was working with a user who uses Windows Fax and Scan to scan documents. One day it stopped scanning and threw an error that read, "A problem prevented the document from being scanned. Please try again or see Help and Support or the information that came with the scanner."
 
All research pointed to running the application as an administrator. Tested running as admin and we were able to scan. We then tried running normally again and the error occurred. Running as an admin was not a viable solution, but as a temporary fix, I created an alternate local admin account and a runas shortcut to run the application with while I searched for a true solution.
 
I found one article that caught my eye, because it referred to issues saving scans as .tiff format, which this user was trying to do. Turns out that when Windows Fax and Scan saves as .tiff, it creates a temporary version of the file and saves it in C:\users\%username%\app data\local\Temp. Once the magic number of 10,000 files is reached, it will no longer accept new temp files. When you run it as an admin since that is technically saving to the admin's temp directory it appears to work magically. I checked the user's temp files and sure enough there were 10,001 .tiff files. Deleted them all, tested scanning again and it scanned without issues.

 

I have been working with a customer on a file server and domain migration project. The original plan was to move the files to our Aspire datacenter on a server that was in a different domain. Since we were moving domains, we were going to have to recreate the file permissions on the new domain. I typically run Robocopy using the /COPYALL (which is equivalent to /COPY:DATSOU) parameter, but since we did not want to copy the security, owner, or auditing information, I used /COPY:DAT.
 
After the initial seeding, the customer prioritized some other moves and postponed the file server migration. During that time, the old datacenter suffered a three day Internet outage. After the outage, the customer decided to move the files while client machines remained on the old domain to prevent another outage. This caused us to need to copy the existing permissions instead of the original plan to translate the permissions at the time of migration.
 
I changed my Robocopy scripts to use /COPYALL instead of /COPY:DAT. Robocopy copied the permissions for the files that had changed or been added since the seeding, but it did not fix the security permissions for the files that had not changed. This is by design as Robocopy only copies permissions when it copies a file. In order to reevaluate the permissions, the /SECFIX parameter must be added. I changed my script to include /COPYALL /SECFIX and it sync the files AND the permissions. This Robocopy takes longer because it has to evaluate security instead of just the files.
 
To keep files and permissions in sync, you need to use the /COPYALL and /SECFIX. You can add /v for verbose logging. The Robocopy command I used to keep the files and permissions in sync was: "robocopy source destination /COPYALL /SECFIX /MIR  /S /E /DCOPY:T /R:0 /W:0 /LOG+:log.log".

 

We had a banking customer with a FiServ application consistently crashing under Windows 10. The crash would always display a .Net framework error. All users of this application were having issues with it, but the severity changed from user to user. One user would crash once every couple of hours, while the other would crash once every other day. No user was doing the exact same thing, and no other errors were showing before the crash. It seemed to be a completely random occurrence.
 
FiServ support could not recreate the issue and advised we update to Windows 10 1803. While updating a PC to test this solution I checked the event logs and noticed a printer kept trying to map every 60 minutes and fail. It just so happened that whenever this printer failed to map, the .Net error would also show up on event logs. Group Policies were refreshing and triggering the printer mapping error. I launched the application and ran a "gpupdate" and sure enough, the application crashed. I looked into the GPO's and found the drive that was mapping the location of the program was set to "replace" instead of "update" or "create". This was causing the file path to be lost every time there was a group policy update. I changed this drive map to "create" and it resolved the issue.

 

I've increasingly had issues getting Excel to open other Excel files if I already had one open. I noticed it happened every time I was working in one of my spreadsheets that contained macros. However after some research, I discovered that Microsoft has intentionally designed this so that if Excel thinks you are editing a cell, it will not allow you to open any other Excel files (even if they are unrelated).
Although there isn't really a true solution, if you hit enter, or simply get out of the cell as if you're editing it, or hit save, you should be able to open other files.

 

If you have ever been annoyed with Office AutoCorrect changing words like "VMware" to "Vmware", you'll be relieved to know there is help for you. In any Office application, go to File->Options->Proofing-> AutoCorrect Options->Exceptions->INitial CAps. There you can add the string in question (ex. "VMw") to the list to stop Office apps from constantly correcting your typing "errors".