Blog: Networking

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.
 

 

I was working with a customer who had accidently deleted some files when copying them to a different drive. When trying to restore them using the Previous Versions option, I got a message saying that the source file name was too long. I tried everything, but eventually the steps below worked for me:
 
  1. Right click on the folder you're trying to restore from shadow copy and chose Previous Versions. Chose a date and click on Open.
  2. Right click on any file or folder within the previous folder and chose Properties. On the General tab copy what's shown in 'location', e.g.: \\localhost\D$\@GMT-2011.09.20-06.00.04\_Data
  3. Open cmd.exe and type in - subst X: \\localhost\D$\@GMT-2011.09.20-06.00.04\_Data
  1. Open PowerShell and use robocopy to copy content of X:  - robocopy Z: D:\Folder\ /E /COPYALL
  1. Check that all files have been copied.
  2. When finished type - subst X: /D in cmd.exe

 

I was working with a customer who uses QuickBooks, and they stopped being able to view PDFs saved in QuickBooks. I tried a few things and even got QuickBooks support on the line to help troubleshoot. They were unable to resolve the issue, but the rep did give me a link to a KB. The link stated that Adobe Reader DC was not supported by QuickBooks and recommended going to Adobe Reader 11.

When QuickBooks does not find a compatible PDF reader it defaults to IE, and IE sees the \\ as a URL and tries to open a nonexistent site. So the solution is to downgrade to Adobe Reader 11. Then you have to make sure that the file you open in QuickBooks is not still pulling the UNC name. You can check this by pressing f2 and looking at the "Location" it should not start with \\. If it does, then you need to close out of QuickBooks, map a network drive to the shared folder that the QuickBooks files reside ie...\\DC1\QBData for instance. Reopen QuickBooks and open the file from the mapped drive you just created. When you press f2 now, the "Location" should say N:\DC1\QBData (or whatever your mapped drive is).

Here is a link to a KB providing a step by step - https://community.intuit.com/articles/1437250

 

 


 

I was investigating a problem with Windows Updates on a laptop with a lot of software on it from a previous user. The updates having problems were the Windows 7 Monthly Cumulative Security patches.

Windows Update would download the patch, install the patch, and then ask to reboot Windows to complete the install.  Once the PC rebooted, the screen would show that Windows was installing updates and sit there at 32%.  The system would eventually reboot itself and change the status to "Failure Configuring Windows Updates. Reverting Changes. Do Not Turn Off Your Computer."  This whole process would take anywhere between 60 - 90 minutes before changes were reverted and I could get back into the system.

Through a  remote console, I connected to the system and wrote down what I observed, including the time.  What I saw were 3 reboots 15 minutes apart with the screen sitting at 32%.  The 15 minutes apart seemed to be consistent.  It was also observed that the Trusted Installer process had high CPU utilization.

From this information, I searched more specifically at CBS log error "Startup: A possible hang was detected on the last boot. [HRESULT = 0x800705b4 - ERROR_TIMEOUT].  I figured that the 15 minutes might end up being a timeout period since it was consistent.

I came across a single article where someone saw something similar with a Windows 2008 R2 domain controller getting stuck at 42% and had opened a premier case with Microsoft: https://social.technet.microsoft.com/Forums/office/en-US/f8fe7d4c-af64-4e65-a007-1f557518628e/windows-2008-r2-sp1-fails-to-install-on-domain-controller-errortimeout-at-42?forum=winservergen

As a solution, they modified the registry value for BlockTimeIncrement in the Trusted Installer service key: HKLM\System\CurrentControlSet\Services\TrustedInstaller.  This appears to be a timeout used for driver enumeration, and by default this is set to 15 minutes.  Increasing this value from 384 (15 Minutes) to 2a30 (3 hours) gave it enough time to wait for whichever component was taking longer than 15 minutes, and eventually the update installed successfully.

 


 

I was working with a customer who reported that his Outlook searches for emails from only user only went back about a month. We did some testing and found that when he searched for emails from another person, they only went back one week. In both searches, I noticed that the number of items found was 250.

250 seemed like a very round number and would have been a huge coincidence that searches for two different people would result in the same number of results found. I did some investigating and found that there is a "feature" in Outlook to limit the search results to increase the speed of searches. 

The feature that enables limiting search results is "Improve search speed by limiting the number of results shown" and is enabled by default. In Outlook 2013 and 2016, this setting limits results to 250 items. In Outlook 2007 and 2010, this setting limits results to 200 items. When this option is unchecked, it will return all items found. Also, if you click "More" at the end of the search results, this setting will be ignored as the "More" button searches on the server and will only return the limited result set.


 

Was working with a customer in which SEP flagged malware located on this week-old PC. Upon investigation, I found that the malware was named MicTray64. A quick bit of research showed this to be a key logger. So we took care of it and changed her passwords. The customer inquired where the malware had come from.

I investigated a little further and that's when I discovered that HP has been shipping PCs with a Key logger preinstalled in their Conexant Audio drivers. The key logger is included in a service called MicTray64 that is meant to check keyboard shortcuts for microphone usage. The key logger launches at log on, and records every key stroke and saves it into a log C:\Users\Public\MicTray.log, so anyone on that pc has access to said log.

Supposedly the log deletes itself when the user logs off. But this file could be easily accessed and it stores everything, including credentials in plain text.

The issue originated because a debugging feature for testing should have been disabled prior to deployment, but that obviously didn't happen. This issue has been found to go back as far as 2015.

To resolve the user needs the most up to date driver, which was released by HP on May 24, 2017. Any driver version prior to this (8.65.186.53 Rev.A) may contain that key logger feature.

 


 

There were intermittent scanning to e-mail issues occurring with an HP Color LaserJet CM4540 MFP.  Initially, scan jobs of all sizes were having trouble going through.  There was an article found that suggested updating the firmware on the device.  After the firmware was updated, it seemed to correct issues with smaller scan jobs, but larger ones were still having issues.

When the scan jobs finished scanning the pages, the device would show on the display “SMTP Protocol Error”.  The e-mails would fail to go out.  During troubleshooting, the device could scan a 10 page document to e-mail (3 times successful), but not a color 46 page document (failed 3 times in a row). 

I tested setting the Exchange server’s hub transport settings from 10 MB to 40 MB.  E-mail sent successfully for the 46 page color scan 4 times with no problems.  What this proved was that the message size was too large to be sent through e-mail based on the e-mail size limit configured in Exchange.

If you happen to see “SMTP Protocol Error” message when trying to scan large documents, chances are the e-mail size is over the limit.


 
 

Recently, I deployed a new vCenter appliance (VCSA) – version 6.5 – with an external Platform Services Controller (PSC) appliance. VMware has made the deployment considerably simpler than it originally was with their first few appliance releases. Instead of having to import an OVA/OVF and do a lot of the configuring yourself, VMware has made an EXE available to configures most of those steps automatically. Simply step through the wizard, providing information such as “what host to deploy the appliance to” and “what deployment model would you like” (external or internal PSC) and the wizard will deploy/configure the appropriate OVA templates.

Unfortunately, the first time that I ran through this wizard, it hung around two-thirds the way through indefinitely. I even left it running overnight and it never completed. Looking through the deployment logs, it turns out that the deployment failed due to licensing issues.

debug: initiateFileTransferFromGuest error: ServerFaultCode: Current license or ESXi version prohibits execution of the requested operation.
debug: Failed to get fileTransferInfo:ServerFaultCode: Current license or ESXi version prohibits execution of the requested operation.
debug: Failed to get url of file in guest vm:ServerFaultCode: Current license or ESXi version prohibits execution of the requested operation. 

Granted, these hosts hadn’t been licensed yet – I had just upgraded the hosts from 6.0 and had assumed the evaluation license was in effect. Apparently not. I installed the full license and tried the deployment once more. Sure enough, that did it …

Moral of the story, if you don’t license your hosts for vCenter (i.e. using the free Hypervisor license), you will not be able to deploy the vCenter appliance.