Server 2012 or 2012R2 - RDP takes long time to logon (10 to 25 minutes)

I have found in our environment we have two particular network settings that have been linked with various issues.  If, when making an RDP connection to a Windows 2012 server the logon takes a long, long time try running these commands from an ELEVATED (Admin) command prompt:

1) netsh int tcp set global rss=disabled

Now test RDP.  If it works normal you are done.  If not, run this second command.

2) netsh int tcp set global chimney=disabled

Try again.  Hopefully it works now.  The values can be checked by running this command

netsh int tcp show global

if the problem re-occurs it can be addressed using a group policy preference modifying the registry settings as shown here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

-EnableTCPChimney and EnableRSS will most likely need to be created as 32-bit REG_DWORDs.

• Right-click EnableTCPChimney, and then click Modify.
• In the Value data box, type 0, and then click OK.
• Right-click EnableRSS, and then click Modify.
• In the Value data box, type 0, and then click OK.

Another option is executing a computer based script running the above two netsh commands.

Repost of Advanced Bash-Scripting Guide

I found this guide helpful.  The original website is:
http://www.tldp.org/LDP/abs/html/

I wanted a pdf copy to read on my tablet but the link on the site is broken.  So I am reposting a pdf version of the guide here (dropbox download):

I found that the problem on the original site was an incorrect URL.  To access the pdf on the original site visit:
http://www.tldp.org/LDP/abs/abs-guide.pdf

Much appreciation to the author Mendel Cooper.  I hope you don't mind me reposting this valuable guide.

Teamviewer issues with screen refresh on remote host

I use Teamviewer a lot.  It is a great tool and for personal use, it is free.  I've never really had any issues with it until recently.  I setup a Linux Mint (Rosa) and when remoting to it using Teamviewer, I've had issues with the remote screen not refreshing properly.  I may close a window, but portions of the window will remain behind, buttons, chunks of the previous window, things like that.  Eventually the desktop will become so cluttered I cannot use it.

Sometimes toggling the quality settings will clear up the screen for the moment but I really need a reliable solution.

So far, the only thing I have found is a setting on the local teamviewer client.  Bring up the top menu, under View, click to expand (if necessary) to show 'custom settings'.  Then select the box for 'better compatibility' or 'improve application compatibility' depending on what version of Teamviewer you are using.

This may help.

Having issues with node-red-contrib-freeboard and your own instance of freeboard?

node-red-contrib-freeboard 

a npm node by urbiworx

The instructions for node-red-contrib-freeboard say 'Just install this plugin to your Node Red installation by using npm: "npm install node-red-contrib-freeboard" in your Node Red root directory'.- That is supposed to be all that needs to be done for this to work...

When I do this, essentially, freeboard is missing.  The freeboard page is not there and attempting to access yields a 'cannot GET /freeboard' error.The issue is the actual freeboard node is getting placed in the same node_modules folder as the node-red-contrib-freeboard node, and that is not what the 'contrib' node expects. Instead, the contrib-freeboard node is looking for the freeboard directory under it's own node_modules directory, but it is not there.  To remedy this issue, we need to move it to the location where node-red-contrib-freeboard expects it to be.

From the command line go to your node-red/node_modules directory.  If you run: ls free* [enter]
you should see freeboard listed as a directory.  Let's move that...

node-red/node_modules $ mv freeboard ./node-red-contrib-freeboard/node_modules/
Now if you take a look at the contents of node-red/node_modules/node-red-contrib-freeboard/node_modules/ you should see freeboard along with a few other directories. Now when you launch node-red, and open http://localhost:1880/freeboard, it should be there. The above is assuming you are using that port and localhost.

Printable version of the Alexa Skills Kit documentation

I took all of the documents linked from this page:
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/getting-started-guide

And made them into a single, printable, PDF file.

Download Here

I removed color from the images and embedded the fonts.  I also applied optimization to reduce size and, although I have not tested yet, made it viewable on mobile devices.

I am not attempting to skirt around the Amazon site.  I know that myself, and some others learn better from a physical document.  I guess since we spent much of our lives studying that way (or atleast I did), it seems more comfortable to me.

This may not be perfect, I apologize ahead of time.  You can always download it and look it over before printing.

Also all section from the list below are included *except* the entire Publishing section.  Please refer to the website for the publishing guidance.

This is the articles included in this PDF, in the same order (minus the Publishing section)

Getting Started

• Getting Started with the Alexa Skills Kit

Voice Design

• Voice Design Handbook
• Defining the Voice Interface

Developing:

• Developing an Alexa Skill as a Lambda Function
• Developing an Alexa Skill as a Web Service
• Handling Requests Sent by Alexa
• Implementing the Built-in Intents
• Linking an Alexa User with a User in Your System

Getting Sample Code:

• Using the Alexa Skills Kit Samples
• Deploying a Sample Skill to AWS Lambda
• Deploying a Sample Skill as a Web Service

Testing:

• Choosing the Invocation Name for an Alexa Skill
• Registering and Managing Alexa Skills in the Developer Portal
• Testing an Alexa Skill
• Deploying a Web Service for an Alexa Skill to AWS Elastic Beanstalk

Publishing:

• Submission Checklist
• Policy Testing
• Security Testing
• Functional Testing
• Voice Interface and User Experience Testing
• Submission Testing Walk-through: Tide Pooler
• Submitting the Skill for Certification

Reference:

• Alexa Skills Kit Interface Reference
• Alexa Skills Kit Interaction Model Reference
• Alexa Skills Kit Java Library Reference
• Speech Synthesis Markup Language (SSML) Reference
• Supported Phrases to Begin a Conversation
• Alexa Skills Kit Glossary
• Migrating to the Improved Built-in and Custom Slot Types

Download (same link as above)

Hue bridge - 14 bulbs - frequent loss of connectivity to bulbs {"reachable":"false"}

After so many wasted hours with the Wink Hub, I really thought the Hue bridge would be create a more reliable, stable environment.  Now that I have been using the Hue bridge for months, I've come to learn my initial hopes were not met.

My primary issue consisted of unpredictable loss of 'reachability' to different bulbs.  This can be seen the Philips Hue app as lights with a (!) symbol next to them.

After much googling I found some things to try to resolve this issue.

Easy - Turn light off and back on

1) Turn the light off and back on.  Wait a minute.  Sometimes the light would rejoin communications.
2) Repeat the above until it worked... when step (1) didn't.

*Save this one if nothing else works - Bulb Reset - Discovery
Time consuming...potential headache... may not even work...
1) Try a different Zigbee channel.  Turn all lights on (make sure the power is on).  Use the Hue app to change the Zigbee channel.  Go around and test the lights.  Under Settings>Lights>tap each one with a (!) make next to it and see if the light flashes on and off.  If so, click ok, and it should be back in contact.  If not, then having to trigger a reset on the bulb (differs by bulb but usually something like turn on, wait a few seconds, turn off, wait at least 3 seconds, repeat 5 times).  The light will give a sign that it reset (GE Link bulbs fade and then go bright, Hue flash (if I remember)).  Then running the auto detection routine in the app (light will flash when detected), name, and should be back on.

Alternate version - perform a reset on the Hue bridge (reset button is on bottom)

Next reset the bulbs using whatever method is used for your type of buld
Use the app to discover the bulb.
Re-add it.

I don't recommend either of the above two approaches unless as a last resort.  Especially if you have a large number of bulbs.  This will take a long time to get fully back up and running, if it succeeds.

When the problem manifests somewhat randomly, and at times works, or at least only affects a small number of bulbs, troubleshooting is a great first step.

• Did the problem start after a software/firmware update to the Hue bridge?
• Did the problem begin after some kind of change?
• Have diagnostics been run on the home network to ensure it is working problem?
• Anything documented online that matches your situation and has a good solution?
• If using a mix of brands of bulbs, are the problems limited to a certain brand?

To make this short... I did all of the above, I spent much time trying to find a pattern, a change to my environment, or anything potentially defective.

Essentially, I believe I may have found the problem.  Although the Hue bridge is using Zigbee to communicate with the lamps, it also shares a frequency spectrum near enough to WiFi signals that interference is a potential issue. Well, if you really want to boost the RF interference, put the WiFi network device, and the Hue bridge near each other.  Proximity increase the potential, or real, RF interference.  By creating interference, the Zigbee network suffers significantly.  So after thorough troubleshooting, my issue was having a WiFi AP too close to the Hue bridge.

Oddly, this was not something I really came across while researching the problem I was experiencing.  It was not until I read a research paper on the potential interference be 2.4Ghz Wifi and Zigbee that I realized my AP and bridge may be too close (approximately 3 feet).  

But, I should point out this was a recent change to my environment, yet I have had these issues on and off for a good while.  Further, the AP was still somewhat close, at about 6 feet.  So I would say most of the time the AP has been fairly close.  Today I moved the WiFi AP to another room, about 24 feet way from the Hue bridge.  I then when to each like that had a (!) next to it in Hue app>Settings>Lights and turned the light off and back on.  After about a minute the (!) went away and I regained control of the device.  This went relatively smooth and quick.  I would say this was the most positive sign I have had regarding stability and easy of communication among the devices connected to the Hue bridge.

Although I made this change just a few hours ago, the way things went so easily and quickly, it makes me think this may have been the predominant issue.  

I should add that a while back I did add more bulbs to my environment to ensure that the mesh network should have adequate proximity between bulbs and a reasonable changes to form good signal strength.

To sum, I wanted to get something posted right away in case it might help others.  I am very tired and realize this may be poorly written and a bit confusing.

I'll come back and review when I am rested.  So, when troubleshooting an unreliable Zigbee mesh network, include RF interference as a culprit between WiFi and the Hue bridge.

Analyzing and troubleshooting network and bandwidth issues

Full diagnostics

http://n1.netalyzr.icsi.berkeley.edu/analysis/

This site reports back a great deal of helpful information.  I recently installed Tomato USB firmware (Shibby) on a Netgear R7000 and as part of the setup process, used this site to help with QOS setup and inspecting for any other issues.