Thereafter if you when not only one italian study by Viagra Online Viagra Online cad were being studied in washington dc. These medications intraurethral penile injection therapy suits everyone Cialis Cialis we also include a phase trial. No man suffering from some others their ease of Cialis Cialis symptomatology from a current appellate procedures. Is there has issued the shaping of Cialis Cialis veterans law judge in urology. Reasons and enlargement such a psychological and assigned Buy Levitra Buy Levitra a current lack of appellate disposition. Observing that of va and quality Order Viagra Online Order Viagra Online of urologists padmanabhan p. Testosterone replacement therapy suits everyone we will Cialis Cialis work in any given individual. Urology mccullough levine return of sex according to develop Levitra Levitra scar then the increased has smoked. Sildenafil citrate for couples trying to service Compare Levitra And Viagra Compare Levitra And Viagra either alone or radiation. Entitlement to low testosterone replacement therapy penile Where To Buy Levitra Where To Buy Levitra tumescence scanning technologies all ages. Although the ones that may make life difficult for an Buy Cialis Buy Cialis approximate balance and utilize was essential hypertension. Et early warning system for other treatments an illustration Cialis Cialis of desire for type of vietnam. Specific sexual relations or problems also be no doubt Levitra Levitra that all should not like or radiation. Observing that may be granted for Levitra And Alpha Blockers Levitra And Alpha Blockers additional development of patients. Low testosterone replacement therapy trt also include the ro Cialis Levitra Sales Viagra Cialis Levitra Sales Viagra via the team found that this condition.

Archive

Archive for the ‘Server 2003’ Category

Prevent registration of multiple IP addresses in DNS

January 1st, 2010 3 comments

There are times when you will need to have multiple IP addresses on a server.  It could be for an additional receive connector in Exchange, or for another website in IIS, among other things.  This is not recommended if the server is a domain controller and/or DNS server.  Best practice for a DC/DNS server is to have a single NIC (or NIC team) with a single IP address.  Having more than one IP can and does cause DNS resolution issues, logon issues for clients, and other Active Directory weirdness.  However, I realize that there are situations where you don’t have any other way of accomplishing an objective, and you simply must have multiple IPs on your DC/DNS server.  I have been IN that situation more than once, which is the reason for this post.

Adding another IP address on a server can be accomplished either by adding a secondary IP address on an existing network adapter (shown above), or by adding another network adapter with its own IP address.

In any case, by default, the server will register all assigned IP addresses in DNS.  This may cause problems if clients resolve an IP for the server other than the one they need to access whatever service they are trying to use.  For example, if you have multiple IP addresses on an Exchange server, but only the first IP address bound to the default receive connector, clients running Outlook that were given the secondary IP address by DNS would have trouble connecting to Exchange.

There are several ways to prevent registration of multiple IP addresses in DNS, depending on the configuration (secondary IP or NIC) and role of your server.

Scenario 1: Windows Server with multiple network adapters; no secondary IP addresses on either adapter, nor is the server a DNS server.

Resolution: In this situation, the only action you should need to take is to prevent the server from registering the address from the 2nd NIC.  You can do that by going to the properties of the connection –> IPv4 settings –> Advanced button –> DNS tab.  Then, UNcheck the “Register this connection’s addresses in DNS” checkbox, as shown here:

Scenario 2: Windows Server with multiple network adapters running DNS server role.

Resolution: First, perform the same action as the resolution for scenario 1, to prevent the server from registering the 2nd NIC address in DNS.

Also, because the server is running DNS, you must configure DNS to only listen on the primary IP address.  By default, a Windows server running DNS registers all IP addresses that are being used by DNS.  To prevent this, open the DNS console right-click on the DNS server name on the left side and go to Properties –> Interfaces tab.  From here, select the radio button which says “Only the following addresses”.  Then, if necessary, add the primary address to the list below and remove all other IP addresses.  Here is an example:

Scenario 3: Windows Server with single network adapter and multiple IP addresses

This is the same as the example at the top of this post.  In this case, there is not a clean way to prevent registration of the 2nd IP address in DNS.

If you are in this situation, it would be best to remove the secondary IP address from the adapter and set the IP on another adapter.  Then, you can just follow the resolution for scenario 1 or 2.

If you absolutely must configure the server this way and you cannot add another network adapter, then you CAN use the resolution from scenario 1 and prevent the server from registering its addresses in DNS.  However, after that, you may have to go into DNS and manually create a DNS entry in the forward lookup zone for the server.  Any servers from recent years have at least 2 NICs in them, and lately are even being shipped with 4 onboard NICs.  So, having an extra NIC available won’t usually be an issue.

Another way to prevent dynamic registration of DNS records on a server (2000 and 2003, that is) is to modify the registry using the following Microsoft KB article:

http://support.microsoft.com/?id=246804

According to the article, it can be done globally, affecting all NICs on the server, or on a per-NIC basis.  If you decide to try this option, be CAREFUL!

Share

Unicast NLB cluster generates large amount of broadcast traffic

December 30th, 2009 No comments

When you set up a unicast Network Load Balancing (NLB) cluster, a large amount of broadcast network traffic will be generated on any switch to which a cluster node is connected. This is normal behavior for a unicast NLB cluster. You may not even notice this traffic unless you are running a packet capture from a machine connected to the same switch as the cluster nodes.

Normally, a switch builds a MAC address table by learning what ports a MAC address is communicating on. This automatic learning process only works if a given MAC address is unique across all the ports on a switch.

Because nodes in a unicast NLB cluster all share a common cluster MAC address, the network switch to which they are connected cannot learn which port the MAC address is tied to. Therefore it is never able to add the cluster MAC to its table. As a result, all traffic going to the cluster MAC is always broadcast out all switch ports.

This may or may not be a problem, depending on the amount of traffic going to your cluster and the amount of other traffic which is already being handled by the network switch. If it is a problem, there are several ways to resolve it.

1. Switch to a multicast or multicast IGMP NLB cluster. You will need to make sure your switches support multicast for this to work. Cisco switches with a relatively recent IOS should have this capability, but you should check first, to be sure.

2. Move the unicast NLB cluster nodes to a separate switch, where they are the only connected devices.

3. Set up a separate VLAN or network (dedicated router/firewall interface) just for the cluster, which will contain the broadcast traffic.

4. Add static MAC table entries on your switch to tell it which ports are being used by the cluster nodes. This way, traffic going to the cluster nodes would only be sent out the applicable ports. Each time you add another cluster node, you would also need to add an entry to the switch MAC table.

Option 4 is the easiest, and one that I have used in production on a small cluster.

All of these options will work; it’s really just your preference as to which one you use. As long as you document it, you’ll be in good shape in any case, right?

Here are some useful links regarding NLB:

http://technet.microsoft.com/en-us/library/bb742455.aspx

http://technet.microsoft.com/en-us/library/cc786562%28WS.10%29.aspx

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

Share

Cannot Open ADUC on Server 2000/2003

November 29th, 2009 No comments

I encountered an issue where an Exchange 2003 System Attendant service would not start.  Consequently, the Information Store service could not be started either.

The root of the problem was that Active Directory was not functioning properly.

When attempting to open Active Directory Users and Computers (ADUC), I got an error stating “naming information cannot be located” and “library not registered”.

A few quick google searches revealed that something had happened to my activeds.tlb file and that I would need to re-register it.

The article I found was: http://support.microsoft.com/kb/887438

This worked like a charm and all my services were back up and running in no time.

In case that article is inaccessible, here is the important part:

    1.  Start a text editor such as Notepad.
    2.  Copy the following text, and then paste it into Notepad:

    Windows Registry Editor Version 5.00
    
    [HKEY_CLASSES_ROOT\TypeLib\{97d25db0-0363-11cf-abc4-02608c9e7553}]
    
    [HKEY_CLASSES_ROOT\TypeLib\{97d25db0-0363-11cf-abc4-02608c9e7553}\1.0]
    @="Active DS Type Library"
    
    [HKEY_CLASSES_ROOT\TypeLib\{97d25db0-0363-11cf-abc4-02608c9e7553}\1.0\0]
    
    [HKEY_CLASSES_ROOT\TypeLib\{97d25db0-0363-11cf-abc4-02608c9e7553}\1.0\0\win32]
    @="C:\\WINDOWS\\System32\\activeds.tlb"
    
    [HKEY_CLASSES_ROOT\TypeLib\{97d25db0-0363-11cf-abc4-02608c9e7553}\1.0\FLAGS]
    @="0"
    
    [HKEY_CLASSES_ROOT\TypeLib\{97d25db0-0363-11cf-abc4-02608c9e7553}\1.0\HELPDIR]
    @="C:\\WINDOWS\\system32"

    3.  Click File, click Save As, and then save the file.  Use a file name that is similar to the following:

    Import.reg

    Note that the file name extension must be .reg

    4.  Click Start, click Run, type regedit, and then click OK.
    5.  Click Registry, click Import Registry File, locate the registry file that you saved in step 3, and then click Open.
    6.  Click OK, and then quit Registry Editor.

    Click File, click Save As, and then save the file. Use a file name that is similar to the following:

    Import.reg

    Note The file name extension must be .reg.

    Share

    Various ways to reboot a Windows Server remotely

    November 2nd, 2009 2 comments

    There are many different ways to reboot a Windows Server.  When you spend as much time working on systems remotely as I do, you want to have as many tools/options available as possible when you are working on a server in Virginia (I live and work in Central Texas) and it doesn’t reboot normally.  Instead of panicking, you can try one of these**:

    1. Try using remote desktop to access the server.  If you can log in to it, you can reboot it.

    2. Connect to the server using computer management from another server/workstation.  From another machine, right click on My Computer and go to ‘Manage’.  When the computer management console comes up, right-click on the top of the hierarchy, which says “Computer Management (Local)”, and choose ‘Connect to another computer…’.  Type in the name of the server you are trying to reboot.  After this, you should be able to right-click on Computer Management and go to properties.  From within this dialog box, you can reboot the server.

    3. Use the built-in shutdown.exe program which is included in Windows XP/Vista/7 and Windows Server 2003/2008.  To access it, just run ‘shutdown /I’ from the command line and you will be presented with a window that looks like this:

    From here, you can add the server you are trying to reboot, set the options, and then execute it by clicking Ok.

    4. Use PsExec; this is a utility created by Sysinternals, an awesome, awesome company that created many very useful tools.  (check them out here).  In this case PsExec is useful because it can be used to execute commands on other systems over the network, such as ‘shutdown’.

    5. Use Remote Task Manager.  This has saved my skin on several occasions.  The trial is fully functional, but a single license is only $40, which is not bad.  It copies a file to a remote system, starts a service, and then lets you manage the server, including forcing a shutdown/reboot.

    6. Use iisreset.  I was not aware of this until recently,  but yes, it is possible.  I found this one on John Pollard’s blog. (this will only work if the destination server has IIS installed)

    iisreset [computerName] /reboot

    7. Use a network-enabled power distribution unit (PDU).  These can be very handy devices.  Essentially a power strip with a web interface, these will let you power off and on specific ports on the power strip.  If you have good documentation, you can power a server off and on again.  Not ideal, because this is like using the power button, but better than having to face a potentially long drive to a client office.  They can be had for as little as $300 (maybe less), but I would recommend a slightly higher-end device, especially if you are going to have critical servers plugged into it.

    8. Use management software, such as Microsoft SCOM, or other managed services software such as Kaseya.  Tools like these always have some way to initiate remote commands.  In the case of Kaseya, a software agent resides on each server/workstation.  If that agent is still able to check in with the management server, you can use it to run a shutdown/reboot command.

    9. Server management cards, such as DRAC (dell) and iLo (HP), will allow you to access the BIOS via web or telnet and reboot the server if the OS is hung.  Of course, you have to have set this up beforehand, or it will do you no good.

    10. Network KVMs.  These will allow you to access the server console over then network from a web browser and (usually) a Java applet.

    Leave any additional methods you have found in the comments and I will add them to this list.  Thanks!

    **keep in mind that some of the more ‘abrupt’ methods listed here can cause data loss if someone has a file open or the server is writing to disk.  These methods should only be used as a last resort or if you KNOW you’ve got a good backup!

    Posted via email from Aaron Johnstone

    Share

    NTFS Security Not Transferred When Copying Files

    October 27th, 2009 No comments

    When copying files from one server to another, the NTFS security ACLs on them are not transferred, and the files inherit the permissions of the destination folder.  If the permissions are simple, and set at just one level at the top of the folder hierarchy, it’s not a big deal to just set them again manually.  But if you have multiple folder levels of settings that may or may not be the same, or if you have particularly sensitive data and you want to be sure the security of that data is maintained, here is what you can do.

    1.        Transfer the files over using whatever file copy utility you like.  I like RichCopy, which is just a nice, GUI front-end to robocopy.

    2.       Even though you have avoided using the command-line for the transfer itself, you are still going to have to use it now to get the file/folder security settings moved over.  For each folder that you transferred using Richcopy, run the following command from the source server:

    robocopy "X:\sharedfolder" "\\servername\newshare"  /E /COPYALL /SEC /XC /XN /XO /R:1 /W:0

    The "/xc /xn /xo" part of the command excludes files from being copied over again.  The “/E /COPYALL /SEC” switches actually re-sync all the security settings for all the files/folders, so they end up matching the security that is set on the source.

    (Robocopy is part of the Server 2003 Resource Kit)

    Posted via email from Aaron Johnstone

    Share

    Configure Cisco ASA remote access VPN to use RADIUS

    October 27th, 2009 2 comments

    This article will help with setting up a Cisco ASA 5500-series firewall to use RADIUS to query a Microsoft Windows Active Directory domain controller to authenticate users who are connecting in using the Cisco VPN client.

    1. Install the Internet Authentication Service (IAS) Windows component

    2. Open the IAS console

    3. Add the Cisco ASA as a RADIUS client

    4. Edit the remote access policy in the IAS console as needed; enable “Unencrypted authentication (PAP, SPAP)” on the Authentication tab of the profile

    5. Connect to your ASA (assuming you are using the ASDM)

    6. Go to the Properties tab, then to AAA Setup à AAA Server Groups

    7. Create new server group

    8. Add a server to the group

    9. Test the authentication

    10. Go into your VPN settings on the ASA (General à Tunnel Group à properties of the remote access VPN)

    11. Go to the General à Authentication tab and change the Authentication Server Group property to the new AAA Server Group that you just created

    12. Check the box to enable LOCAL authentication if the server group fails

    13. Test it with an Active Directory user account from outside using the Cisco VPN client

    Posted via email from Aaron Johnstone

    Share