Blog: Networking

I installed a new Synology NAS with two folder shares with encryption enabled.  The Synology is configured to check for updates, but not install them.  This is so we can control that this is performed when there is no backup activity going on. After installing the updates the NAS is automatically rebooted.

After the reboot when I went to make sure I could still access the file shares on the device, I discovered they appeared to be gone.  In a panic, I checked the disk volumes within the Synology Web UI and saw they still had quite a bit of used disk space, so the data was still there.

As it turns out, the shared folders need to be mounted after a reboot.  Select each shared folder and under the encryption dropdown will be an option to mount.  This will bring up a prompt for the encryption key password which you must provide.  After mounting the folders, I could access the file shares again over CIFS.



Occasionally, I have the need to open a Visio diagram but don't have a need to create or modify them. So, the Visio viewer seemed to be an ideal option. However, after installing the viewer (I tried this with both 32-bit and 64-bit versions), I was still unable to open a Visio file.

The best I could get was Windows asking what I would like to use to open the file and Visio viewer wasn't an option. After drilling down to find the executable file, I found the viewer (VPREVIEW.EXE) would display a message saying "This program can only run from within another program” when I tried to execute it. I discovered the Visio viewer is designed to use ActiveX controls within Internet Explorer. Since I had disabled IE 11 on my system (using the "Turn Windows features on or off"), the viewer had nowhere to execute since Edge doesn't support ActiveX.

I found a Chrome plug-in in the Chrome web store that will allow me to view Visio files from inside Chrome. However, it requires me to click on a tag in the Chrome header and then drag the Visio file into the Chrome window.

So, the alternatives appear to be to enable IE 11 or use a Chrome plug-in. 



Brocade (now owned by Ruckus) switches have two versions of code loaded by default to two different partitions. The primary partition contains a layer 2 image, while the secondary partition contains a layer 3 image. For the ICX-6610 switches, the layer 2 image is named FCXSxxxxx.bin and the layer 3 image is named FCXRxxxxx.bin. Notice the S and R to notate layer 2 (switching) and layer 3 (routing), respectively. In order to enable layer 3 features on an ICX-6610 switch, you must switch to the layer 3 image by updating the boot record. You can see the following link for more information:

Also, you are able to update these switches using a manifest file, which allows it to do most of the update for you. Using the manifest file will only update the running code version. To update the non-running code, you can use TFTP.

Brocade has recently sold their product lines to several companies. The product line for larger equipment was purchased by Broadcom and the website can still be used for information for these devices. The product line for smaller equipment (what most of our customers own) was sold to Ruckus and information/downloads can only be found on the website.




Recently, quiesce snapshot jobs for some customers kept showing up as failed in Veeam with the error "msg.snapshot.error-quiescingerror".

After exhausting several research options I called VMware Support and we began sifting through event log files on the server as well as looking at the VSS writers and how VMware Tools was installed.

Looking at the log files on the ESX host the server was on led to this article:

A folder named backupScripts.d gets created and references a path C:\Scripts\PrepostSnap\ which is empty. Therefore the job fails. The fix is found below:

  1. Log in to the Windows virtual machine that is experiencing the issue.
  2. Navigate to C:\Program Files\VMware\VMware Tools.
  3. Rename the backupscripts.d folder to backupscripts.d.old

If that folder is not present, and/or if the job still fails, the VMware services checked.


I was working with a customer who called in a disk space issue. I ran SpaceSniffer and discovered  there were 92GB of files in a temp folder and nearly all were cab files.

My research discovered that on Windows 7 64bit and Server 2008 R2 the makecab.exe utility breaks whenever a log file is over 2GB. The problem is that the cabinet file format cannot store files larger than 2GB and it breaks the compression process as a result. Consequently all new logs created afterwards never get created properly and C:\Windows\Temp fills up with corrupt cabinet files; as much as 200MB+ a day. 

The only solution is to delete all of the corrupted cab files from the temp folder and the initially corrupted log file in the CBS folder. Here is a link to the article explaining this issue.


I was working on a Windows Server 2016 system that I had already configured and put in production.  While I was monitoring the resources of the server when I noticed the processes for Windows Defender show up in the task manager as if it were scanning files.  This server already had a different AV solution installed.
As it turns out, you need to uninstall Windows Defender feature manually on Windows Server 2016 (‚Äč).  Windows Server 2016 will not disable Windows Defender automatically.
"On Windows Server 2016, Windows Defender AV will not enter passive or disabled mode if you have also installed a third-party antivirus product. If you install a third-party antivirus product, you should uninstall Windows Defender AV on Windows Server 2016 to prevent problems caused by having multiple antivirus products installed on a machine." 


Recently, I built a brand new Server 2016 system for one of our customer domains. This was the first Server 2016 server in this domain, but not the first one I had built – the procedures should have been fairly straightforward and similar to other build-outs in the past.

After the initial install, I went to the Settings app and tried to install the available Windows Updates. However every time that I tried to open Settings, I got this message saying the app had been blocked:

Strangely enough, I was the system administrator the message kindly passed the blame onto, and I don’t remember blocking the Settings app – especially on the first 2016 server in this network. As is typically the case in a lot of these random “issues” there was a Microsoft KB to the rescue explaining what was going on. 

This issue occurs when an administrator has deployed an application control policy (AppLocker) on the computer. By design, all Microsoft Store apps are blocked if an AppLocker policy is applied. Well, we do have AppLocker in use on this domain due to restricting access to applications for licensing purposes. Unfortunately, in order for me to even attempt to “unblock” the Settings app (which apparently qualifies as a Microsoft Store app), I needed to install the GPO tools on my new server. From there, I could set up the exception appropriately and get into Settings to install patches.

After the first reboot, I wanted to go into the users and groups and configure the access to allow the various groups of individuals to log in and do stuff. Clicking on the start menu does nothing. Hitting the windows key does nothing. Right click on the start menu works. Keyboard shortcuts (Win+R) works. Apparently the start menu qualifies as a Microsoft Store app as well. I loosened the restriction on this GPO and was able to get in and complete my setup.


The Meraki MX84 firewalls are subject to the Cisco Clock Signal Component issue that affects many firewalls and routers. With a typical Cisco device, we would copy the config from the old device and put it on the new device. Since Meraki devices are cloud managed, copying the config in this way is not possible. I called Meraki tech support and they said this could be accomplished by using a process called a “MX Cold Swap”. Meraki documents that process here:
After performing the MX Cold Swap, everything seemed to be working, until we tested email. Inbound and outbound emails were not being delivered and email was queuing on the Exchange server. Since our visibility into the Meraki devices is limited to the web portal, I called Meraki tech support for assistance troubleshooting. After troubleshooting, we found that that main IP address was working, but the other public IP addresses that were NAT’d were not working. We tried rebooting the ISP’s equipment onsite to clear any MAC address tables, but that did not solve the issue. The Meraki tech support engineer found an article in their knowledge base that describes this issue:
The solution is to log into the local status page of the Meraki firewall and set the main IP to the NAT’d IP that is not working. This adds the NAT’d IP addresses to the ARP cache on the upstream routers. After a few seconds, you change the main IP address back to the correct address. Repeat for any other NAT’d IP addresses. This solution worked for the NAT’d IP addresses that originally were not working.


I couple weeks ago, I was trying to find a way to copy a whole folder of file names all at once. I found a quick way to do it using a PowerShell command.

To do it, hold down Shift and right click on the folder that has the file names you would like to copy. Click Open PowerShell window here from the drop down menu to open up PowerShell. To get the file names, use the command, Get-ChildItem –name . The names of the files will be displayed in PowerShell, and to copy the file names, just highlight the file names and they will be copied to your clipboard:


I was at a customer location and needing to reflash a thin client that had become unusable.  After obtaining the imaging utilities needed to write a bootable flash image to a removable USB, I only had one type of USB thumbdrive available, an 8 GB SanDisk Cruzer.
Once everything was ready to start creating the bootable image to the USB thumbdrive, the dropdown to select a target device was empty.  
Further research into the issue I came across multiple articles about the SanDisk Cruzers showing up as a "fixed disk" instead of "removable USB device".  This appears to be hard-coded into the device from a bit that is set, and there's really not a way to flip the bit to specify that it is a removable USB device (which is what the imaging utility wanted).
I went to the nearest big-box store, ignored 90% of their selection which were SanDisk Cruzers, and purchased the cheapest, most generic USB thumbdrive they had.  It worked with the imaging utility without a single problem and was detected as a removable USB device.