Blog

SQL Server Access from remote client machines:  If you have a named instance of SQL Server, then there are specific things you need to do to allow clients to access the SQL database remotely. The default instance of SQL Server uses port 1433. Even for the default instance you will probably want to open an Inbound Rule on the SQL host that allows any inbound communication on port 1433 or allows the sqlsvr.exe access via this port.  For named instances, the ports that are used to talk to the SQL box are by default dynamic. The SQL browser can advertise the exact ports used by the named instances if UDP is allowed through the firewall on port 1434. A complete explanation of these issues can be found in this document: [more] http://blogs.technet.com/b/nexthop/archive/2011/04/12/using-lync-server-2010-with-a-custom-sql-server-network-configuration.aspx . This document specifically addresses the LYNC client connection, but the principals are the same regardless of the application.

Awhile back, we had a problem with two of our Cisco Aironet devices at a customer site that kept dropping their wireless connection to each other.  The old radios had been replaced by these newer aironet devices while still keeping the same antennas.

The error message, among many, in the logs stated: “Packet to client <clientname> reached max retries, removing the client”.

At first, we thought that they might be overshooting the other end by having their signal strength too high.  We tried lowering the signal strength but it didn’t really help the issue that much.  We tried scanning the airwaves for interference, but couldn’t decisively find anything troublesome with the channel frequencies.  We also checked the alignment of the antennas and saw that they appeared to be in the same position that they had been for quite some time.

I came across a wireless troubleshooting guide by Cisco that mentioned that the problem can be an indication of a bad RF. It suggested putting the command “packet retries 128 drop-packet” on both access points as a workaround for bad RF.  After this command was applied, we the wireless connection stopped disconnecting.

Background setup:

This site has VMware vSphere 5.0 hosts which are connecting to NFS datastores on a NetApp SAN/NAS.  There is a dedicated switch stack of Dell PowerConnect 5524 switches between the NetApp and the VMWare hosts.

Issue description:

Over the last couple weeks I have been seeing where VMWare virtual machines would pause or in some cases disconnect sessions.  The Windows event log would consistently record an Event ID 129 with a Source of LSI_SAS: "Reset to device, \Device\RaidPort0, was issued."  I did some further research and found that this event is usually generated when there is high I/O on the SAN.  However, the SAN at this location wasn’t experiencing high I/O. 

I started to notice the following NFS disconnect error while I was logged into the SAN:
nfsd.tcp.close.idle.notify:warning]: Shutting down idle connection to client (192.168.1.10) where receive side flow control has been enabled. There are 0 bytes in the receive buffer. [more]

Resolution:

Per NetApp’s best practice document, flow-control should be disabled on the storage network when using modern hardware.  I had flow-control enabled on the switch and the SAN and this apparently was causing the disconnect issues. 
http://media.netapp.com/documents/tr-3749.pdf

A review of more than 200,000 4-digit PINs used on mobile phones revealed the following as the most common (in order):

1. 1234 (used by more than 4% of the sample group)<
2. 0000
3. 2580 (straight down the middle of the keypad)<
4. 1111
5. 5555
6. 5683 (spells LOVE)
7. 0852 (straight up the middle of the keypad)
8. 2222
9. 1212
10. 1998

The 10 most frequently used PINs represent more than 14% of the total sampled.  Thus, with this distribution of PINs, you have a 1 in 7 chance of guessing the correct one in 10 tries. [more]

Years are always popular when coming up with a 4-digit PIN (see number 10 above).  So, birth year, graduation year, etc. would also be a good guess if these are known

Regardless, it's a very good idea to recommend people NOT use these particular PINs (at least the first 9 plus predictable years).

I had replaced the power supplies for the blade enclosures for a customer.  When they had all been replaced, I noticed that one enclosure had power warning for all but two blade servers.  I rebooted one thinking it would clear the alert, but it certainly did not.  I researched the issue on the HP website to no avail.  In desperation, I shut down the server blade completely, waited, and then restarted the server.  That finally cleared the warning.  I shut down the rest of the blades, and then turned them back on and all of the warnings had cleared.

Vertafore performed an AMS360 software upgrade and not one of  the client systems would function properly. The problem was seen on physical PCs located in the main office. None of the View desktops (multi-user Virtual Desktop environments) used by remote users had the issue that was seen in the main office. The vender said it was a permissions issue, but after trial and error it was determined the problem was not a permissions issue. By comparing the affected systems with the View desktops that worked properly after the upgrade,  we found that for some reason the information in the Local folder in the users profile was not getting the updated settings. To resolve the problem CoNetrix performed a reboot; logged in as the administrator and removed the users profile. Then uninstalled and reinstalled the AMS workstation client, followed by logging  the user back in, which reloaded their roaming profile and rebuild the Local and Local Low profile folders. When we would login to AMS as the user, the system check would run as it should and add the updated DLLs and information to the users Local profile folder. After these steps were completed, each user’s AMS worked as it should. However, the process also required repair of each user’s Zixmail and Zywave installations due to rebuilding the Local and Local Low folders.

All the repairs were completed without elevating the user’s rights.

Also as stated above, none of the multi-user Virtual Desktop environment systems had this problem.  After the Internet Explorer 9 upgrade, each of the View systems were recomposed which removes the user’s profile and rebuilds the user’s Local and Local Low folders on first login.

An article by lifehacker (http://lifehacker.com/5896093/use-an-analog-alarm-clock-to-disable-forced-screensavers) showed how someone discovered a new use for an analog alarm clock.  The second hand registers as movement if the mouse is placed on top of the clock (see picture below) when not in use.

So, if you are inspecting the workplace and see a mouse perched on top of a clock, this may be the reason. [more]

A customer reported a problem with one of their users not being able to get email on his iPhone. His  phone would setup his account successfully, but when he went to the mail app, it would say “The connection to the mail server failed.” The customer tried setting up another user’s mailbox on his phone and it work correctly. I setup both accounts on my iPhone and saw the same results. I checked his account in Exchange to make sure ActiveSync was enabled. After some research, I found that the user’s Active Directory account must inherit permissions from the parent folder for email to sync.

To change this setting, first open Active Directory.

Enable Advanced Features – (View > Advanced Features).

Find the user’s account in Active Directory and open the Properties.

Go the Security tab > Advanced > Check “Include inheritable permissions from this object’s parent”. [more]

Click Apply and close Active Directory.

Refresh the mail app on the phone and mail should start flowing.

Bit Locker encryption on my new laptop asked for a recovery key every time I booted the system. Nothing had been changed within the system to cause this behavior. In an attempt to stop this from happening I un-encrypted and re-encrypted the drive. When the re-encryption was complete I rebooted and it asked for the recovery key. I went into the Bit Locker settings and suspended the encryption and reboot without an issue. I then re-enabled the encryption, reboot and it did not ask for the recovery key again. So if your system begins prompting for the recovery key. Disable and then re-enable Bit Locker and it resolves the problem.