Blog

I had needed to make a change to a customer’s WPAD file to add a direct access  location. I made my changes and tested it only to find out that it didn’t work. I decided that I would check and make sure the client could access the WPAD file, so I tested access to HTTP:// SERVERNAME/ WPAD.dat. I was able to see the changes I had saved in the file.  However, the client still didn’t seem to be following the rules. I tried changing the  Automatic Settings in Internet Explorer Proxy settings to use HTTP:// SERVERNAME/ WPAD.dat specifically as the proxy script to use.  As long as I had the Automatic Settings unchecked and the path to the WPAD file defined in the script box, it worked. However, I needed to make sure it would work with Automatic Settings instead. [more]

What I found out was that a client gets it’s instructions about the location of the WPAD file to use through DHCP option 252. Upon checking the settings of this option, I found that it was using HTTP://WPAD/WPAD.dat instead of SERVERNAME. The DNS entry for WPAD was an alias that pointed to SERVERNAME. I went back to the web browser and went to HTTP://WPAD/WPAD.dat.  I discovered that it did not have the changes that I had made even though HTTP://SERVERNAME/WPAD.dat was correct.  On the WPAD server, I restarted IIS and checked it again.  This time, both WPAD.dat files had my changes and the Automatic Settings began working successfully.

It appeared to me what happened was that IIS was serving a cached version of the WPAD.dat file when browsers tried to connect to the DNS alias while the actual server name was not cached. 

In Windows XP there was the advanced file type options which could be changed to open each Excel file in a new instance of Excel. In Windows 7 that advanced option is not available. So, when mulple Excel spreadsheets are opened in Office 2007/2010 on a Windows 7 system, all will open in the same instance. A solution is available, but it involves making lile changes in the registry. I recommend making back up for just in case.  Then follow these steps: [more]

1. start -> run -> regedit
2. Go to  HKEY_CLASSES_ ROOT/ Excel.Sheet.8/ shell/Open/command
3. Double Click on (Default) and write "C:\Program Files\Microso Office\Office12 \EXCEL.EXE" /e "% 1" for Office 2007 or "C:\Program Files\Microso Office\Office14 \EXCEL.EXE" /e "% 1" for Office 2010.
4. Right Click on Command, choose "rename", and add something to the name (for example 2 (command2))  
5. Go to HKEY_CLASSES_ROOT/Excel.Sheet.8/ shell/Open/ ddeexec
6. Right Click on the folder ddeexec, choose "rename", and add something to the name (for example 2 (ddeexec2))
7. Go to HKEY_CLASSES_RO OT/Excel.Sheet.12/ shell/Open/command 
8. Double Click on (Default) and write "C:\Program Files\Microso Office\Office12 \EXCEL.EXE" /e "% 1" for Office 2007 or  "C:\Program Files\Microso Office\Office14 \EXCEL.EXE" /e "% 1" for Office 2010. 
9. Right Click on Command, choose "rename", and add something to the name  (for example 2 (command2)). 

No restart is needed. Excel will now open a new instance for each file opened. I have found that opening mulple .csv files will stay in the same instance, but all .xslx files will open in their own instance. 

You should avoid using the same LUN on more than one VMware vCenter environments. If this rule is not followed, deleting a datastore from one vCenter will cause it to appear as "dead" on the other vCenter when using the following command: esxcli storage core device list [more]

If a rescan HBA's is performed at this point, all management tools may become unresponsive.  To avoid this, the LUN needs to be marked as disabled, rescanned, then removed from the disabled list:

1.   esxcli storage core device set -steate=off -d <NAA ID> (whatever the worldwide name is for that LUN)
2. rescan HBA's 
3. esxcli storage core device detached remove -d <NAA ID>

If everything is already unresponsive, "localcli" may be substituted for "esxcli."

I had upgraded a terminal server from Office XP to 2010 recently and users were getting pop up warnings about autodiscover.domain.com and remote.domain.com names not matching the certificate.  Exchange happened to be setup with both external and internal autodiscover URLs pointing to an external domain address. 

In order to resolve this issue completely, I had to change the internal URLs used by autodiscover in four places.  The URLs need to be configured using the Exchange Power Shell.  The commands I list basically get the value first, and then set the value.  [more]

This article helped me find most of the commands: http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/configuring-exchange-server-2007-web-services-urls.html

Get-AutoDiscoverVirtualDirectory | fl
Set-AutoDiscoverVirtualDirectory -internalUrl “https://internalname/Autodiscover/Autodiscover.xml” -identity “<IDENTITY>”  

Get-ClientAccessServer | fl
Set-ClientAccessServer -Identity "<IDENTITY>” -AutodiscoverServiceInternalURI "https://internalname/Autodiscover/Autodiscover.xml"  

Up to this point, this fixed the SCP URL and allowed the Autodiscover E-mail test to return data.

I had to change the following internal URLs on these services also:

Get-WebServicesVirtualDirectory | fl
Set-WebServicesVirtualDirectory -Identity "<IDENTITY>" -InternalUrl "https://internalname/EWS/Exchange.asmx"

Get-UMVirtualDirectory | fl
Set-UMVirtualDirectory -Identity "<IDENTITY>" -InternalUrl "https://internalname/UnifiedMessaging/Service.asmx"

I was setting up a new volume on our MSA2324fc for an Alpha system to access. The Alpha has been running on an existing volume on the MSA for about a year. I got to the point where the Alpha could see the new volume from the console, but the OpenVMS operating system could not see it.  I verified everything was set up identically on the new volume, except I noticed that the "Volume Description" field was blank on the new volume. It was set to "9" which was the logical unit number on the old volume.  [more]

I could find no way to change this in the web based UI, so I tried connecting to the MSA with telnet. The show volume command listed the volume description, but I noticed a command "set volume <NAME> ovms-uid <ID>." I tried setting that to 4, the LUN of the new volume, and that showed up in the volume description field. Then the OpenVMS operating system could see the new volume.

 I never  thought the contents of a description field woudl have mattered, but it did in the case.

I was performing a PST e-mail import task for a migration being done recently.  The user’s PST files were larger than the mailbox quota limits set at 200 MB.  Once the import reached 200 MB of data, it stopped and gave me an error in powershell. 

After examining the quota limit on the mailbox, I increased the size and tried the import again.  It kept failing immediately and the logs showed that the quota limit had been reached. 

After some searching, I found out that there is a waiting period between changing the quota limit and it actually taking effect.  To make the change happen immediately, I found that you can restart the Microsoft Exchange Information Store service, and it will update the quota limits on the mailbox.

When working on a compromised system, it's always good to have a "toolkit" available on read-only media (in case built-in utilities, like netstat, have been replaced on the compromised machine to hide the attackers activities).  However, you also need to know how to USE the tools in your toolkit.  At my training last week I was working to recover a compromised web server.  After doing some cleanup and removing some clearly malicious software, I tried to use netstat to verify the current listening ports/services on the machine (along with associated processes).  The local netstat on the machine had been hacked to return no output, but thankfully the netstat EXE on my "toolkit" CD was working.  I quickly combed through the list of ports that were labeled "LISTENING".  I didn't see anything listening that was out of the ordinary.  However, when the following prompt popped up I knew the attacker still had remote access to my machine. [more]

Upon a closer look at the netstat output, I noticed there was an "ESTABLISHED" connection to TCP port 23 on my host (typically used for telnet).  P0wn3d!

Lesson learned… verify ESTABLISHED sessions in addition to actively LISTENING services.

If you ever need to copy some text from one machine to another and they both have Internet access, then you can use dontpad.com.  Create your own path, save anything there and then copy it anywhere.  Of course there is no privacy policy, service level agreement, or anything like that.  You can also use this to share information with others.  If you want to keep the data private, encrypt it.  Here’s how easy it is on Linux  or Windows with Cygwin installed (and probably OS X):

cat | ccrypt -K <your secret key> -e | base64
<your plain text goes here>
^D

Paste into http://dontpad.com/<any path>, copy to destination.

cat | base64 -d | ccrypt -d -K <your secret key>
<your encrypted text goes here>
^D

I was assigned recently to a task that had been started by another network engineer. The initial problem started when software updates were applied to the server. The network adapter lost its driver and wasn’t able to talk to the network, let alone the world. He was able to restore network connectivity by reinstalling that driver and resolving other network issues that had arisen, but was unable to fix an issue where network drives were not mapping to the server in the time he had available to him.

When I took a look at it the next morning, all signs led to the network card going bad and needing to be replaced. However, as I was continuing to troubleshoot, I noticed that they had the Network Threat Protection module for Symantec Endpoint Protection (v. 11.0.4) installed. I created a rule on the firewall to open all traffic between sources on the 10.0.0.0/8 network and immediately people were able to map network drives and start working.