Blog: Networking

I had applied Windows updates to a customer’s Windows 2008 R2 server that had Microsoft Threat Management Gateway installed, and I could not RDP to the server after rebooting.  I connected to the server locally and could tell from netstat that the server was not listening at all on port 3389.

It turns out that there was a problem with the RDP-tcp protocol not working because it was configured to listen on all available network adapters.  This being a proxy server, it had internal and dmz network adapters.  To fix this issue, set the RDP-tcp protocol to only bind to the internal network adapter. [more]

  • Open Remote Desktop Session Host Configuration.
  • Open th/e properties of the RDP-Tcp protocol underneath Connections.
  • In the Network Adapter tab, change the setting from “All network adapters configured with this protocol” to the specified internal network adapter and hit apply.
  • On the Actions bar to the right, click Disable Connection and then Enable Connection to reset it.
  • Run netstat to confirm that the server is listening on port 3389 again.

 

While configuring a new Windows 7 laptop I attempted to setup a new VPN connection.  It kept defaulting to a dial-up connection. I verified the steps I was taking on my own Windows 7 laptop and then repeated it again, but it had the same results. I tried copying the VPN connection to the system and it still would try to use dial up. I tried setting up the VPN using the local administrator account, domain administrator account, and domain user account only to find the same results each time.  I even disabled and uninstalled the modem and it still default to dial up.

After some research, I opened the device manager, enabled the “Show hidden devices” option, and under “Non-Plug and Play Drivers” I found NDProxy with a yellow exclamation mark. [more]

NDProxy, according to Microsoft is "a system-provided driver that interfaces NDISWAN and CoNDIS WAN drivers (WAN miniport drivers, call managers, and miniport call managers) to the TAPI services" - see http://msdn.microsoft.com/en-us/library/ff568322.aspx for more details.  NDProxy has been linked to slow boot, BSOD and other issues in Vista.

To fix the problem right click on NDProxy and select properties, go to the second tab (Driver) and look at the “Current Status” section, it says it is “Stopped”. Choose the option to start it then reboot. (Do not change the startup type) After the reboot NDProxy will no longer have an exclamation icon (i.e. it started OK) and it shows “Started” in the “Current Status”.


 

I was recently troubleshooting a problem where a terminal server, that happened to be a VMware virtual machine, could not browse the network.  Opening Explorer when drives were mapped would hang Explorer.  Opening Explorer with no drives mapped, but attempting to browse to a network location would hang Explorer.  Troubleshooting was complicated by this being a production server.

First, I cloned the server in VMware, renamed it, and rejoined the domain under the new name.  This allowed me to troubleshoot without further disrupting the users. [more]

Next, after extensive testing (resetting TCP/IP, cleaning DNS, running HijackThis, C-Cleaner, removing a bunch of software, etc.), I found that the Network Provider Order was incorrect.  VMware shared folders was listed first, followed by terminal services and then Windows Networking.  I reordered the list so that Windows Networking was first in the list, logged off and back on, and everything started working normally.  I replicated the fix to the production TS2 and users are able to browse the network.


 

After some updates were installed on an SBS 2008 server, Outlook started prompting for credentials from time to time.  Searching the Internet for this was futile.  Many incidents of this happening with many different solutions exist, but none of these worked.  A $99 case with Microsoft was opened and the tech that called back knew exactly what the cause of the problem was.  This update (http://support.microsoft.com/kb/973917) enabled kernel mode authentication with IIS and it was causing Outlook’s user mode authentication to fail. This article:

http://blogs.technet.com/b/sbs/archive/2010/02/16/outlook-2007-credential-prompts-in-small-business-server-2008.aspx

explains what broke and how to fix it by running this command as an admin:

%windir%\System32\inetsrv\appcmd.exe set config -section:windowsAuthentication /useKernelMode:false


 

I had a user that was trying to access OWA from home.  The user had the correct website and the credentials were being entered correctly, however they kept getting an error message about insufficient access.  This error was preventing the user from using OWA at all.  I could see the user account showed that they had logged in successfully by looking at the timestamps on the Active Directory User object. 
 
The problem turned out to be caused from non-inherited permissions in Active Directory.
 
The following information explaining why this happened was found from a Technet forum thread.

If your Exchange 2007 OWA is failing for a user after the mailbox is migrated from Exchange 2003 to Exchange 2007, the user account should be checked on the security tab under advanced to see if it has "Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here."

  1. Open up Active Directory Users and Computers
  2. Go to the View menu, Advanced.
  3. Locate the user in AD, right click, properties.  Jump to the security tab.
  4. Click "Advanced" next to the "For special permissions or for advanced settings, click Advanced.
  5. Click "Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here." Check box and apply.
  6. Click OK and OK again.

Once changed and replicated OWA works. This is checked by default but is turned off for accounts with administrative privileges.
 
So how does this get turned off? Well if the account is an administrative account or was ever an administrative account previously. It will be turned off automatically.
 
Reference the following.
XADM: Do Not Assign Mailboxes to Administrative Accounts
http://support.microsoft.com/kb/328753 which says
 
By not assigning mailboxes to accounts with administrative permissions, you avoid security issues related to "elevation of privilege" attacks. For example, in an elevation of privilege attack, a security hole exists in which Group X is made a member of the Domain Administrators group, and access control lists (ACLs) exist on Group X that permit Group Y to modify Group X. In this situation, members of Group Y can make themselves members of Group X and so become a member of the Domain Administrators group.
 
To help guard against such security issues, the Administrator account and accounts that are members of these security groups are not permitted to inherit permissions. On the Security tab of the group or account's properties page, you can see that the Allow inheritable permissions from parent to propagate to this object check box is not selected. Moreover, if you click to select this check box, a Microsoft Windows 2000 system task soon clears it automatically. Clearing the check box is a function of Windows 2000 intended to prevent hackers from playing with security and inappropriately increasing their permissions to the level of administrator.
 
As a side effect of this inheritance setting, if you do try to use a mailbox assigned to an administrative account, you may not be able to log on to or resolve the mailbox. Also, in Exchange System Manager, although the Administrator account can have an Exchange 2000 alias and an Exchange 2000 mailbox, it does not have e-mail addresses. The Recipient Update Service, which updates the e-mail addresses and several other attributes, does not have the authority to update objects if the Allow inheritable permissions from parent to propagate to this object check box is not selected.


 

I am working on a large upgrade of Exchange 2007 to Exchange 2010 at one of our customers. One of the “to-do” items is to check and make sure that all of the exchange web services are healthy. The issue that I ran across was a discrepancy between what the powershell command for testing the EWS returned and what Outlook returned. The powershell command to test all EWS is the following: [more]
 
[PS] D:\Documents and Settings\cnx_user\Desktop>Test-OutlookWebServices | fl
Id      : 1003
Type    : Information
Message : About to test AutoDiscover with the e-mail address [email protected].
Id      : 1006
Type    : Information
Message : The Autodiscover service was contacted at https://server.domain.dom/Autodiscover/Autodiscover.xml.
Id      : 1016
Type    : Success
Message : [EXCH]-Successfully contacted the AS service at https://server.domain.dom/EWS/Exchange.asmx. The elapsed time was 296 milliseconds.
Id      : 1015
Type    : Success
Message : [EXCH]-Successfully contacted the OAB service at https://server.domain.dom/EWS/Exchange.asmx. The elapsed time was 0 milliseconds.
Id      : 1014
Type    : Success
Message : [EXCH]-Successfully contacted the UM service at https://server.domain.dom/UnifiedMessaging/Service.asmx. The elapsed time was 171 milliseconds.
Id      : 1006
Type    : Success
Message : The Autodiscover service was tested successfully.
 
Ok, so it looks like everything was working as expected, until I tried testing from Outlook under my account. Outlook hides the “Test Email AutoConfiguration” option well. You have to hold down CTRL and right-click the Outlook icon in the system tray to see the option. This option basically testing the EWS. Uncheck the “Use Guesssmart” and “Secure Guesssmart Authenication” options, put in your password and click Test. I kept getting this error on the log tab.
 
Autodiscover to https://server.domain.dom/Autodiscover/autodiscover.xml FAILED (0x800C8203)
 
I spent a good half hour trying to figure out what might be wrong when I finally realized that the EWS testing tool was using my username (cnx_user) followed by the AD domain. See below:

Well, it just so happens that this customer does not deploy two aliases per user mailbox (user@ad_domain & user@public_domain) as is the default for Exchange. Their default address policy only configures the public-facing alias on all mailboxes which is [email protected]. The Outlook EWS tools was using an alias that didn’t exist... changing it to [email protected] instead of [email protected] solved the problem.


 

I was adding a new SCSI/SATA controller card to an HP MSA 1510i. I had shut down the unit to perform the work and after rebooting I could not connect to the management interface. I checked the small interface on the front and the system was attempting to get a DHCP address. I reset the address for management and was able to connect but the password had reset to the default. At that point I determined it had dumped its configuration. [more]

The LUNs were fine just could not communicate over iSCSI. If you have ever configure a MSA 1510i you know they are not very straight forward. I was able to get everything back communicating and the VMware servers back online without too much trouble. Lesson learned was to make sure and document the configuration of a device or back it up. Unfortunately the MSA 1510i does not allow configuration backups. It’s also good to document because I had lost access to information at our office, such as passwords and IPs, because the ISA server (which is a VM) was offline.


 

When performing a migration from ISA 2000 to Forefront TMG, I set up the perimeter networks as part of the “perimeter” network object.  I ran into a problem when I went to create server publishing rules. They did not work.  I had to remove the subnets from the perimeter group so that the network interface would show up as part of the “external” network object.  Once the addresses on the outside interface were in the “external” network object, I was able to successfully create server publishing rules.
 
Also, Forefront TMG now allows the published port to be different from the port on the internal server.  This is useful when creating publishing rules for multiple RDP servers, for example.

 

I came across a Smart UPS 1500 that needed a battery replacement recently.  After the replacement battery was installed, I ran a self-test like I normally do to clear alarms on the unit.  I noticed that the self-test reported that the battery had a runtime remaining of 0 minutes and a 20% capacity.   I decided to let the battery charge up to 100% and then try a runtime calibration.

Later that evening, the UPS was reporting that the battery had 100% capacity and a runtime of 3 minutes with a very minimal load.  I ran the runtime calibration and the runtime dropped immediately to 0 minutes with a 20% charge.  I thought that the battery might be faulty at this point. 

The customer happened to have another battery there to try.  We put the battery in and testing showed the same exact symptoms.  Therefore the problem must be with the UPS and not the batteries.

APC's forum quotes "The battery constants give the battery status via their life expectancy. If the battery ages and is 'exhausted', the constant is overwritten. The management software calculates the runtime of the UPS with these constants.  If the battery is now replaced, a self test must be done with the new batteries. Through it, the red battery replace indicator goes out and the battery constants should be reset to the standard settings. This does not occur in some cases. Therefore, the constants must be reset manually in order to correct this situation."

Through research, I came across this article http://www.rm.com/Support/TechnicalArticle.asp?cref=TEC817072 which describes how to reset the battery constant manually.  The only problem is that this has to be done by physically connecting the serial cable to the UPS, so I was not able to try this out yet.  Since each UPS has different constant variables, you will have to call APC support and ask them what to set it to. [more]

Here are the steps listed using Hyperterminal from the hyperlink above:

In order to successfully reset the battery constant, all accompanying devices (SmartSlot Accessories such as Interface Expander, Web/SNMP Management Card) must be removed from the SmartSlot or from the Com port of the UPS.

  1. Please shut off all connected load, switch off the UPS, pull the power plug of the UPS.
  2. Switch off the UPS once again till you hear a click.
  3. Remove all accompanying devices.
  4. Turn on the UPS again and connect a computer with Windows 95/98/ME, Windows NT 4.0 or Win 2000, which runs on Hyperterminal using one of the cables mentioned under the requirements.
  5. Close Powerchute plus-Server. With Windows NT/2000, the UPS service must be stopped. If you are using PowerChute Business Edition, stop the Agent *V service.
  6. Perform a Battery Constants check.
  7. Start a Hyperterminal session with the UPS.  Note: Ensure that there are no accessories plugged into the UPS. (Web Management cards, IO Relay cards etc)
  8. Start Hyperterminal by going to Start, Programs, Accessories, Communications, Hyperterminal.
  9. You will be requested to enter a name and a symbol. Enter a favourite name and click on OK. When a message that a modem must be installed appears, you can ignore this message.
  10. Select the serial port to which black serial cable is connected to.  The correct settings for the COM-connection are 2400 Baud, 8 data bits, 1 Stop bit, no parity, protocol Xon/Xoff. In this window, click on Advanced and make sure that the option FIFO activated is unchecked. Click twice on OK.
  11. Check if there is a connection (Type Shift + Y, should return **SM** ). Do not enter any other characters via Hyperterminal other than that described in these instructions because this can cause irreparable damage to the UPS
  12. Type **1**, wait 2-3 secs and type **1** again (Should return **Prog**)
  13. Enter a **0** and the UPS reports the present value of the battery constant.  If this value does not correspond to the default value that was given to you by RM Support or APC , it must be changed.
  14. If this value is not correct, press **+** or **-** until the correct value is returned.
  15. Press **R** to close the session. (Should return **Bye**)
  16. Enter **<Shift> Y**, the UPS reports again with **SM**.
  17. Enter **0** once again and check if the UPS reports back the standard setting that has been set.
  18. Close Hyperterminal, start the UPS again and check the UPS runtime in the management software.

 

Level Platforms has partnered with a company called Ninite to provide prebuilt installers for many non-Microsoft utilities and applications.  These include Java, Adobe Reader, and Adobe Flash.  With the new scripting features in Level Platforms MW2011 we should be able use the packages provided by Ninite to centrally manage updates to these applications.  If you want to try Ninite, they provide free installers packages that are completely functional, but with some restrictions for enterprise automation.

https://ninite.com/help/how-ninite-works/