Showing posts with label Microsoft. Show all posts
Showing posts with label Microsoft. Show all posts

Tuesday, February 28, 2012

Neuron: Sharepoint Slow via UNC

Microsoft's Sharepoint can be accessed by a web browser, or via a UNC path as if it is a file server.  We store a lot of documentation on Sharepoint and I find it easiest to manage via UNC path.  Lately I have noticed that my access to the UNC path could take almost a minute.  After digging around a bit, I found that this is a known issue with Windows 7.  Going to Internet Explorer's properties (even if you don't use IE as your browser) and shutting off automatic proxy detection will speed things back up.


Tuesday, February 21, 2012

Neuron: Lan Settings in Internet Explorer Disabled

Today my colleague and I ran across two vendor supplied machines running IE 6.0 (we're not supposed to update them) that we needed to get connected to the Internet for the vendor's support.  Our proxy server, Ironport WSA, has an issue when used transparently with IE 6.0 that requires you to explicitly configure it as the proxy server.  Unfortunately the vendor had disabled access to the LAN Settings even to the Administrator login.

Thankfully, you can't disable the registry.  There are two ways for these settings to be disabled.  The first is as an all users setting and the other is per user.

To enable the settings if done for all users open regedit and go to:
HKLM\Software\Policies\Microsoft\Internet Explorer\Control Panel
In that key will be two values, Proxy and Connection Settings.  Set both to 0 to enable the settings.

The per user setting is in a similar path in the user hive.
HKCU\Software\Policies\Microsoft\Internet Explorer\Restrictions
Likewise the keys need changed to 0.

Friday, February 25, 2011

Microsoft Clustering and Ping

We often take the venerable ping utility for granted.  Simply tell it what to ping and it does it.  When you're in a Microsoft cluster environment though you might not get what you really wanted.

Let's say that you're testing a firewall rule for a particular cluster IP address.  If you start to ping from any of the cluster nodes, you will actually ping from that node's IP address.  This obviously won't test the firewall rule correctly.  Instead you want to ping from the cluster's IP address.  To do this you just need to look at the command line options for ping.

C:\Users\storyb.000>ping -?
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]]
            [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name
Options:
    -t             Ping the specified host until stopped.
                   To see statistics and continue - type Control-Break;
                   To stop - type Control-C.
    -a             Resolve addresses to hostnames.
    -n count       Number of echo requests to send.
    -l size        Send buffer size.
    -f             Set Don't Fragment flag in packet (IPv4-only).
    -i TTL         Time To Live.
    -v TOS         Type Of Service (IPv4-only. This setting has been deprecated
                   and has no effect on the type of service field in the IP Head
er).
    -r count       Record route for count hops (IPv4-only).
    -s count       Timestamp for count hops (IPv4-only).
    -j host-list   Loose source route along host-list (IPv4-only).
    -k host-list   Strict source route along host-list (IPv4-only).
    -w timeout     Timeout in milliseconds to wait for each reply.
    -R             Use routing header to test reverse route also (IPv6-only).
    -S srcaddr     Source address to use.
    -4             Force using IPv4.
    -6             Force using IPv6.



So from looking over this list it looks like -S will save the day which it will.  By using ping -S <sourceIP> <dstIP> you can ping any host from the cluster's virtual IP.

Tuesday, February 8, 2011

Internet Explorer 6 -- Ere he says he's not dead yet.

Contrary to reports that say IE 6 is dead, unfortunately it is not.  Today I got an urgent call to come help an outside technician that was installing a new remote support tool on some equipment.  He was having problems because he couldn't get past our IronPort WSA web filter.  I trotted up expecting to just add a few device IPs temporarily to the proxy bypass list until he was done downloading things.  Unfortunately the application needed web access all of the time and used the installed version of IE which of course was IE 6.  This is where it gets hairy.

Ironport WSA is configured to use passthrough NTLM authentication to authenticate users for Internet access.  This works great for IE 7+, Firefox and Chrome.  Unfortunately IE6 is braindead when it comes to NTLM authentication and only works with some NTLM proxies.  This means that I have to hard code any IE6 clients to use our proxy explicitly.

Moral of the story, vendors please update your "appliances" to modern software versions.