subject:"A real puzzler..."

Re: A real puzzler...

2010-11-23 Thread Kurt Buff

Had not specifically looked there, but had searched the registry for
the rogue address, and didn't find it.

I just now did look in that part of the registry, with no result -
it's not there.

The weirdest thing about this is that the machine *will not* issue an
echo-reply in response to an echo-request for the rogue address, but
*will* respond to the echo-request or an ARP indicating it has the
address.

Very strange

Kurt

On Tue, Nov 23, 2010 at 21:14, Ken Schaefer  wrote:
> Apologies if this was suggested before: IPv4 addresses seems to be stored in:
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
>
> If you can find it in there, maybe nuke the relevant key and see if the 
> problem goes away?
>
> Cheers
> Ken
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Wednesday, 24 November 2010 4:08 AM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> Unfortunately, no. The machine holding the phantom IP address is a physical 
> box - the DC for the AU office.
>
> I'm just about on top of standing up a VM for a new DC, DCPROMO'ing down the 
> offending box and seeing what comes to light from that, and if that doesn't 
> resolve it, I may have the part-time guy scratch the box and re-install.
>
> Kurt
>
> On Tue, Nov 23, 2010 at 06:04, Kelsey, John  wrote:
>> I had a similar problem to this on one of my VMs.  It had to do with the way 
>> the vm box was connected to the lan.  I had to set the vm nic load balancing 
>> to 'route based on IP hash'  Until I did that, I had all kinds of strange 
>> issues with IP addresses mapping back to the wrong mac addresses.  Not sure 
>> if it applies to your situation, but if your vm box has multiple network 
>> lines trunked up to a switch it might be something to look at.
>>
>> Thanks
>>
>> -----Original Message-
>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> Sent: Monday, November 22, 2010 11:56 PM
>> To: NT System Admin Issues
>> Subject: Re: A real puzzler...
>>
>> Unfortunately, no.
>>
>> Already tried that - no phantom NIC.
>>
>> On Mon, Nov 22, 2010 at 15:56, Hilderbrand, Doug
>>  wrote:
>>> Try this trick from a previous ntsysadmin post. I bet you have a phantom 
>>> nic on that DC.
>>>
>>> 
>>> I never heard of this before, and just read it on the NT Sys Admin news 
>>> feed.
>>>
>>> …To work around this behavior and display phantom devices when you use the 
>>> Show hidden devices command:
>>> Click Start, click Run, type cmd.exe, and then press ENTER.
>>> Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
>>> Type Start DEVMGMT.MSC, and then press ENTER.
>>> Click View, and then click Show Hidden Devices.
>>> Expand the Network Adapters tree.
>>> Right-click the dimmed network adapter, and then click Uninstall.
>>>
>>>
>>> Definitely going into my bag o’ tricks.
>>> 
>>>
>>>
>>>
>>> Doug Hilderbrand | Systems Analyst, Information Technology | Crane
>>> Aerospace & Electronics
>>>
>>>
>>> -Original Message-
>>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>>> Sent: Tuesday, November 16, 2010 4:49 PM
>>> To: NT System Admin Issues
>>> Subject: Re: A real puzzler...
>>>
>>> On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
>>>> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>>>>> So, I'm away from the office in a VMWare class, and find that the
>>>>> part time IT guy in the office did a test, and it seems to confirm
>>>>> that the DC is holding onto 192.168.61.30.
>>>>
>>>>  Well, that narrows it down quite a bit, which is a good thing.
>>>>
>>>>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and
>>>> Remote Access) on the suspect DC?  I remember RRAS holding on to an
>>>> IP address confused my minion once.
>>>>
>>>> -- Ben
>>>
>>> I did check those - RRAS has never been configured, and the results of your 
>>> suggested tests are below:
>>>
>>> H:\>ipconfig /all
>>>
>>> Windows IP Configuration
>>>
>>>   Host Name . . . . . . . . . . . . : auad1
>>>   Primary Dns Suffix  . . . . . . . : example.com
>>>   Node Type . . . . . . . . . . . . : Hybrid
>>>   IP Routing Enabled. . . . . . . . : No
>>>   WINS Pr

RE: A real puzzler...

2010-11-23 Thread Ken Schaefer

Apologies if this was suggested before: IPv4 addresses seems to be stored in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces

If you can find it in there, maybe nuke the relevant key and see if the problem 
goes away?

Cheers
Ken

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Wednesday, 24 November 2010 4:08 AM
To: NT System Admin Issues
Subject: Re: A real puzzler...

Unfortunately, no. The machine holding the phantom IP address is a physical box 
- the DC for the AU office.

I'm just about on top of standing up a VM for a new DC, DCPROMO'ing down the 
offending box and seeing what comes to light from that, and if that doesn't 
resolve it, I may have the part-time guy scratch the box and re-install.

Kurt

On Tue, Nov 23, 2010 at 06:04, Kelsey, John  wrote:
> I had a similar problem to this on one of my VMs.  It had to do with the way 
> the vm box was connected to the lan.  I had to set the vm nic load balancing 
> to 'route based on IP hash'  Until I did that, I had all kinds of strange 
> issues with IP addresses mapping back to the wrong mac addresses.  Not sure 
> if it applies to your situation, but if your vm box has multiple network 
> lines trunked up to a switch it might be something to look at.
>
> Thanks
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Monday, November 22, 2010 11:56 PM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> Unfortunately, no.
>
> Already tried that - no phantom NIC.
>
> On Mon, Nov 22, 2010 at 15:56, Hilderbrand, Doug 
>  wrote:
>> Try this trick from a previous ntsysadmin post. I bet you have a phantom nic 
>> on that DC.
>>
>> 
>> I never heard of this before, and just read it on the NT Sys Admin news feed.
>>
>> …To work around this behavior and display phantom devices when you use the 
>> Show hidden devices command:
>> Click Start, click Run, type cmd.exe, and then press ENTER.
>> Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
>> Type Start DEVMGMT.MSC, and then press ENTER.
>> Click View, and then click Show Hidden Devices.
>> Expand the Network Adapters tree.
>> Right-click the dimmed network adapter, and then click Uninstall.
>>
>>
>> Definitely going into my bag o’ tricks.
>> 
>>
>>
>>
>> Doug Hilderbrand | Systems Analyst, Information Technology | Crane 
>> Aerospace & Electronics
>>
>>
>> -Original Message-
>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> Sent: Tuesday, November 16, 2010 4:49 PM
>> To: NT System Admin Issues
>> Subject: Re: A real puzzler...
>>
>> On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
>>> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>>>> So, I'm away from the office in a VMWare class, and find that the 
>>>> part time IT guy in the office did a test, and it seems to confirm 
>>>> that the DC is holding onto 192.168.61.30.
>>>
>>>  Well, that narrows it down quite a bit, which is a good thing.
>>>
>>>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and 
>>> Remote Access) on the suspect DC?  I remember RRAS holding on to an 
>>> IP address confused my minion once.
>>>
>>> -- Ben
>>
>> I did check those - RRAS has never been configured, and the results of your 
>> suggested tests are below:
>>
>> H:\>ipconfig /all
>>
>> Windows IP Configuration
>>
>>   Host Name . . . . . . . . . . . . : auad1
>>   Primary Dns Suffix  . . . . . . . : example.com
>>   Node Type . . . . . . . . . . . . : Hybrid
>>   IP Routing Enabled. . . . . . . . : No
>>   WINS Proxy Enabled. . . . . . . . : No
>>   DNS Suffix Search List. . . . . . : example.com
>>
>> Ethernet adapter Local Area Connection:
>>
>>   Connection-specific DNS Suffix  . :
>>   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network 
>> Connection
>>   Physical Address. . . . . . . . . : 00-14-22-21-B2-87
>>   DHCP Enabled. . . . . . . . . . . : No
>>   IP Address. . . . . . . . . . . . : 192.168.61.31
>>   Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>   Default Gateway . . . . . . . . . : 192.168.61.1
>>   DNS Servers . . . . . . . . . . . : 192.168.61.31
>>                                       192.168.10.191
>>   Primary WINS Server . . . . . . . : 192.168.61.31
>>   Secondary WINS Server . . . . . . : 192.168.10.191
>>
>> H:\>getmac
>>
>> Physical Address    Transport Name
>>

Re: A real puzzler...

2010-11-23 Thread Kurt Buff

Unfortunately, no. The machine holding the phantom IP address is a
physical box - the DC for the AU office.

I'm just about on top of standing up a VM for a new DC, DCPROMO'ing
down the offending box and seeing what comes to light from that, and
if that doesn't resolve it, I may have the part-time guy scratch the
box and re-install.

Kurt

On Tue, Nov 23, 2010 at 06:04, Kelsey, John  wrote:
> I had a similar problem to this on one of my VMs.  It had to do with the way 
> the vm box was connected to the lan.  I had to set the vm nic load balancing 
> to 'route based on IP hash'  Until I did that, I had all kinds of strange 
> issues with IP addresses mapping back to the wrong mac addresses.  Not sure 
> if it applies to your situation, but if your vm box has multiple network 
> lines trunked up to a switch it might be something to look at.
>
> Thanks
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Monday, November 22, 2010 11:56 PM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> Unfortunately, no.
>
> Already tried that - no phantom NIC.
>
> On Mon, Nov 22, 2010 at 15:56, Hilderbrand, Doug
>  wrote:
>> Try this trick from a previous ntsysadmin post. I bet you have a phantom nic 
>> on that DC.
>>
>> 
>> I never heard of this before, and just read it on the NT Sys Admin news feed.
>>
>> …To work around this behavior and display phantom devices when you use the 
>> Show hidden devices command:
>> Click Start, click Run, type cmd.exe, and then press ENTER.
>> Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
>> Type Start DEVMGMT.MSC, and then press ENTER.
>> Click View, and then click Show Hidden Devices.
>> Expand the Network Adapters tree.
>> Right-click the dimmed network adapter, and then click Uninstall.
>>
>>
>> Definitely going into my bag o’ tricks.
>> 
>>
>>
>>
>> Doug Hilderbrand | Systems Analyst, Information Technology | Crane Aerospace 
>> & Electronics
>>
>>
>> -Original Message-
>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> Sent: Tuesday, November 16, 2010 4:49 PM
>> To: NT System Admin Issues
>> Subject: Re: A real puzzler...
>>
>> On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
>>> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>>>> So, I'm away from the office in a VMWare class, and find that the
>>>> part time IT guy in the office did a test, and it seems to confirm
>>>> that the DC is holding onto 192.168.61.30.
>>>
>>>  Well, that narrows it down quite a bit, which is a good thing.
>>>
>>>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and
>>> Remote Access) on the suspect DC?  I remember RRAS holding on to an IP
>>> address confused my minion once.
>>>
>>> -- Ben
>>
>> I did check those - RRAS has never been configured, and the results of your 
>> suggested tests are below:
>>
>> H:\>ipconfig /all
>>
>> Windows IP Configuration
>>
>>   Host Name . . . . . . . . . . . . : auad1
>>   Primary Dns Suffix  . . . . . . . : example.com
>>   Node Type . . . . . . . . . . . . : Hybrid
>>   IP Routing Enabled. . . . . . . . : No
>>   WINS Proxy Enabled. . . . . . . . : No
>>   DNS Suffix Search List. . . . . . : example.com
>>
>> Ethernet adapter Local Area Connection:
>>
>>   Connection-specific DNS Suffix  . :
>>   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
>>   Physical Address. . . . . . . . . : 00-14-22-21-B2-87
>>   DHCP Enabled. . . . . . . . . . . : No
>>   IP Address. . . . . . . . . . . . : 192.168.61.31
>>   Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>   Default Gateway . . . . . . . . . : 192.168.61.1
>>   DNS Servers . . . . . . . . . . . : 192.168.61.31
>>                                       192.168.10.191
>>   Primary WINS Server . . . . . . . : 192.168.61.31
>>   Secondary WINS Server . . . . . . : 192.168.10.191
>>
>> H:\>getmac
>>
>> Physical Address    Transport Name
>> === 
>> ==
>> 00-14-22-21-B2-87   \Device\Tcpip_{872C9721-6C4B-41FB-9D0F-53C3F8FDB82E}
>> Disabled            Disconnected
>>
>> H:\>netsh -c interface show interface
>>
>> Admin State    State          Type             Interface Name
>>

RE: A real puzzler...

2010-11-23 Thread Kelsey, John

I had a similar problem to this on one of my VMs.  It had to do with the way 
the vm box was connected to the lan.  I had to set the vm nic load balancing to 
'route based on IP hash'  Until I did that, I had all kinds of strange issues 
with IP addresses mapping back to the wrong mac addresses.  Not sure if it 
applies to your situation, but if your vm box has multiple network lines 
trunked up to a switch it might be something to look at.

Thanks 

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Monday, November 22, 2010 11:56 PM
To: NT System Admin Issues
Subject: Re: A real puzzler...

Unfortunately, no.

Already tried that - no phantom NIC.

On Mon, Nov 22, 2010 at 15:56, Hilderbrand, Doug
 wrote:
> Try this trick from a previous ntsysadmin post. I bet you have a phantom nic 
> on that DC.
>
> 
> I never heard of this before, and just read it on the NT Sys Admin news feed.
>
> …To work around this behavior and display phantom devices when you use the 
> Show hidden devices command:
> Click Start, click Run, type cmd.exe, and then press ENTER.
> Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
> Type Start DEVMGMT.MSC, and then press ENTER.
> Click View, and then click Show Hidden Devices.
> Expand the Network Adapters tree.
> Right-click the dimmed network adapter, and then click Uninstall.
>
>
> Definitely going into my bag o’ tricks.
> 
>
>
>
> Doug Hilderbrand | Systems Analyst, Information Technology | Crane Aerospace 
> & Electronics
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Tuesday, November 16, 2010 4:49 PM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
>> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>>> So, I'm away from the office in a VMWare class, and find that the
>>> part time IT guy in the office did a test, and it seems to confirm
>>> that the DC is holding onto 192.168.61.30.
>>
>>  Well, that narrows it down quite a bit, which is a good thing.
>>
>>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and
>> Remote Access) on the suspect DC?  I remember RRAS holding on to an IP
>> address confused my minion once.
>>
>> -- Ben
>
> I did check those - RRAS has never been configured, and the results of your 
> suggested tests are below:
>
> H:\>ipconfig /all
>
> Windows IP Configuration
>
>   Host Name . . . . . . . . . . . . : auad1
>   Primary Dns Suffix  . . . . . . . : example.com
>   Node Type . . . . . . . . . . . . : Hybrid
>   IP Routing Enabled. . . . . . . . : No
>   WINS Proxy Enabled. . . . . . . . : No
>   DNS Suffix Search List. . . . . . : example.com
>
> Ethernet adapter Local Area Connection:
>
>   Connection-specific DNS Suffix  . :
>   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
>   Physical Address. . . . . . . . . : 00-14-22-21-B2-87
>   DHCP Enabled. . . . . . . . . . . : No
>   IP Address. . . . . . . . . . . . : 192.168.61.31
>   Subnet Mask . . . . . . . . . . . : 255.255.255.0
>   Default Gateway . . . . . . . . . : 192.168.61.1
>   DNS Servers . . . . . . . . . . . : 192.168.61.31
>                                       192.168.10.191
>   Primary WINS Server . . . . . . . : 192.168.61.31
>   Secondary WINS Server . . . . . . : 192.168.10.191
>
> H:\>getmac
>
> Physical Address    Transport Name
> === ==
> 00-14-22-21-B2-87   \Device\Tcpip_{872C9721-6C4B-41FB-9D0F-53C3F8FDB82E}
> Disabled            Disconnected
>
> H:\>netsh -c interface show interface
>
> Admin State    State          Type             Interface Name
> -
> Enabled        Unreachable    Dedicated        Local Area Connection
> Enabled        Unreachable    Dedicated        Local Area Connection 2
> Enabled        Unreachable    Internal         Internal
> Enabled        Unreachable    Loopback         Loopback
>
>
> H:\>netsh -c interface show alias
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>
> 
> Check out the new Crane Aerospace &am

Re: A real puzzler...

2010-11-22 Thread Kurt Buff

Unfortunately, no.

Already tried that - no phantom NIC.

On Mon, Nov 22, 2010 at 15:56, Hilderbrand, Doug
 wrote:
> Try this trick from a previous ntsysadmin post. I bet you have a phantom nic 
> on that DC.
>
> 
> I never heard of this before, and just read it on the NT Sys Admin news feed.
>
> …To work around this behavior and display phantom devices when you use the 
> Show hidden devices command:
> Click Start, click Run, type cmd.exe, and then press ENTER.
> Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
> Type Start DEVMGMT.MSC, and then press ENTER.
> Click View, and then click Show Hidden Devices.
> Expand the Network Adapters tree.
> Right-click the dimmed network adapter, and then click Uninstall.
>
>
> Definitely going into my bag o’ tricks.
> 
>
>
>
> Doug Hilderbrand | Systems Analyst, Information Technology | Crane Aerospace 
> & Electronics
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Tuesday, November 16, 2010 4:49 PM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
>> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>>> So, I'm away from the office in a VMWare class, and find that the
>>> part time IT guy in the office did a test, and it seems to confirm
>>> that the DC is holding onto 192.168.61.30.
>>
>>  Well, that narrows it down quite a bit, which is a good thing.
>>
>>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and
>> Remote Access) on the suspect DC?  I remember RRAS holding on to an IP
>> address confused my minion once.
>>
>> -- Ben
>
> I did check those - RRAS has never been configured, and the results of your 
> suggested tests are below:
>
> H:\>ipconfig /all
>
> Windows IP Configuration
>
>   Host Name . . . . . . . . . . . . : auad1
>   Primary Dns Suffix  . . . . . . . : example.com
>   Node Type . . . . . . . . . . . . : Hybrid
>   IP Routing Enabled. . . . . . . . : No
>   WINS Proxy Enabled. . . . . . . . : No
>   DNS Suffix Search List. . . . . . : example.com
>
> Ethernet adapter Local Area Connection:
>
>   Connection-specific DNS Suffix  . :
>   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
>   Physical Address. . . . . . . . . : 00-14-22-21-B2-87
>   DHCP Enabled. . . . . . . . . . . : No
>   IP Address. . . . . . . . . . . . : 192.168.61.31
>   Subnet Mask . . . . . . . . . . . : 255.255.255.0
>   Default Gateway . . . . . . . . . : 192.168.61.1
>   DNS Servers . . . . . . . . . . . : 192.168.61.31
>                                       192.168.10.191
>   Primary WINS Server . . . . . . . : 192.168.61.31
>   Secondary WINS Server . . . . . . : 192.168.10.191
>
> H:\>getmac
>
> Physical Address    Transport Name
> === ==
> 00-14-22-21-B2-87   \Device\Tcpip_{872C9721-6C4B-41FB-9D0F-53C3F8FDB82E}
> Disabled            Disconnected
>
> H:\>netsh -c interface show interface
>
> Admin State    State          Type             Interface Name
> -
> Enabled        Unreachable    Dedicated        Local Area Connection
> Enabled        Unreachable    Dedicated        Local Area Connection 2
> Enabled        Unreachable    Internal         Internal
> Enabled        Unreachable    Loopback         Loopback
>
>
> H:\>netsh -c interface show alias
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>
> 
> Check out the new Crane Aerospace & Electronics Newsroom!
> http://newsroom.craneae.com
> Like us on Facebook!
> http://www.facebook.com/home.php?#!/pages/Crane-Aerospace-Electronics/163305413682908
>
> We value your opinion!  How may we serve you better?
> Please click the survey link to tell us how we are doing:
> http://www.craneae.com/ContactUs/VoiceofCustomer.aspx
> Your feedback is of the utmost importance to us. Thank you for your time.
> 
> Crane Aerospace & Electronics Confidentiality Statement:
> The information contained in this email message may be privileged and is
>

RE: A real puzzler...

2010-11-22 Thread Hilderbrand, Doug

Try this trick from a previous ntsysadmin post. I bet you have a phantom nic on 
that DC.

I never heard of this before, and just read it on the NT Sys Admin news feed. 

…To work around this behavior and display phantom devices when you use the Show 
hidden devices command: 
Click Start, click Run, type cmd.exe, and then press ENTER.
Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
Type Start DEVMGMT.MSC, and then press ENTER.
Click View, and then click Show Hidden Devices.
Expand the Network Adapters tree.
Right-click the dimmed network adapter, and then click Uninstall.

Definitely going into my bag o’ tricks.

Doug Hilderbrand | Systems Analyst, Information Technology | Crane Aerospace & 
Electronics

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Tuesday, November 16, 2010 4:49 PM
To: NT System Admin Issues
Subject: Re: A real puzzler...

On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>> So, I'm away from the office in a VMWare class, and find that the 
>> part time IT guy in the office did a test, and it seems to confirm 
>> that the DC is holding onto 192.168.61.30.
>
>  Well, that narrows it down quite a bit, which is a good thing.
>
>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and 
> Remote Access) on the suspect DC?  I remember RRAS holding on to an IP 
> address confused my minion once.
>
> -- Ben

I did check those - RRAS has never been configured, and the results of your 
suggested tests are below:

H:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : auad1
   Primary Dns Suffix  . . . . . . . : example.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : example.com

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
   Physical Address. . . . . . . . . : 00-14-22-21-B2-87
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.61.31
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.61.1
   DNS Servers . . . . . . . . . . . : 192.168.61.31
   192.168.10.191
   Primary WINS Server . . . . . . . : 192.168.61.31
   Secondary WINS Server . . . . . . : 192.168.10.191

H:\>getmac

Physical AddressTransport Name
=== ==
00-14-22-21-B2-87   \Device\Tcpip_{872C9721-6C4B-41FB-9D0F-53C3F8FDB82E}
DisabledDisconnected

H:\>netsh -c interface show interface

Admin StateState  Type Interface Name
-
EnabledUnreachableDedicatedLocal Area Connection
EnabledUnreachableDedicatedLocal Area Connection 2
EnabledUnreachableInternal Internal
EnabledUnreachableLoopback Loopback

H:\>netsh -c interface show alias

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Check out the new Crane Aerospace & Electronics Newsroom!
http://newsroom.craneae.com
Like us on Facebook!
http://www.facebook.com/home.php?#!/pages/Crane-Aerospace-Electronics/163305413682908

We value your opinion!  How may we serve you better? 
Please click the survey link to tell us how we are doing:
http://www.craneae.com/ContactUs/VoiceofCustomer.aspx
Your feedback is of the utmost importance to us. Thank you for your time.

Crane Aerospace & Electronics Confidentiality Statement:
The information contained in this email message may be privileged and is 
confidential information intended only for the use of the recipient, or any 
employee or agent responsible to deliver it to the intended recipient. Any 
unauthorized use, distribution or copying of this information is strictly 
prohibited 
and may be unlawful. If you have received this communication in error, please 
notify 
the sender immediately and destroy the original message and all attachments 
from 
your electronic files.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business

Re: A real puzzler...

2010-11-16 Thread Kurt Buff

On Tue, Nov 16, 2010 at 16:17, Ben Scott  wrote:
> On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
>> So, I'm away from the office in a VMWare class, and find that the part
>> time IT guy in the office did a test, and it seems to confirm that the
>> DC is holding onto 192.168.61.30.
>
>  Well, that narrows it down quite a bit, which is a good thing.
>
>  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and
> Remote Access) on the suspect DC?  I remember RRAS holding on to an IP
> address confused my minion once.
>
> -- Ben

I did check those - RRAS has never been configured, and the results of
your suggested tests are below:

H:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : auad1
   Primary Dns Suffix  . . . . . . . : example.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : example.com

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
   Physical Address. . . . . . . . . : 00-14-22-21-B2-87
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.61.31
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.61.1
   DNS Servers . . . . . . . . . . . : 192.168.61.31
   192.168.10.191
   Primary WINS Server . . . . . . . : 192.168.61.31
   Secondary WINS Server . . . . . . : 192.168.10.191

H:\>getmac

Physical AddressTransport Name
=== ==
00-14-22-21-B2-87   \Device\Tcpip_{872C9721-6C4B-41FB-9D0F-53C3F8FDB82E}
DisabledDisconnected

H:\>netsh -c interface show interface

Admin StateState  Type Interface Name
-
EnabledUnreachableDedicatedLocal Area Connection
EnabledUnreachableDedicatedLocal Area Connection 2
EnabledUnreachableInternal Internal
EnabledUnreachableLoopback Loopback


H:\>netsh -c interface show alias

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-11-16 Thread Ben Scott

On Tue, Nov 16, 2010 at 7:03 PM, Kurt Buff  wrote:
> So, I'm away from the office in a VMWare class, and find that the part
> time IT guy in the office did a test, and it seems to confirm that the
> DC is holding onto 192.168.61.30.

  Well, that narrows it down quite a bit, which is a good thing.

  Did you ever try "ipconfig /all" and/or checking RRAS (Routing and
Remote Access) on the suspect DC?  I remember RRAS holding on to an IP
address confused my minion once.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-11-16 Thread Kurt Buff

Oh good grief...

So, I'm away from the office in a VMWare class, and find that the part
time IT guy in the office did a test, and it seems to confirm that the
DC is holding onto 192.168.61.30.

He pinged the address from his box, checked his arp table, and the MAC
address for the DC shows.

He then pulled the cable from the DC, pinged again, and had no entries
in the ARP table.

I'm querying him on whether he got a response to the ping at the
prompt, or if the only evidence was an entry in the ARP table in his
machine.

Any more thoughts?

On Fri, Oct 29, 2010 at 22:49, Kurt Buff  wrote:
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having
> difficulty wrapping my brain around. I have a theory, but it is still
> a strange situation, and any feedback anyone can provide would be
> appreciated.
>
> The AU office has a server, which I've just recently stood up, using
> an address assigned by DHCP. This is not ideal, obviously, but the
> thing refuses to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error
> message that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I
> get no answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a
> machine that had been used in the US office about two years ago. We
> did a P2V on it, and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have
> expected the the MAC to change when it got the virtual NIC), but
> AFAICT this shouldn't make a difference, since they are in different
> subnets entirely, with different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-11-01 Thread Kurt Buff

I've checked WINS - that IP address doesn't exist in the WINS tables.

We don't use LMHOSTS - I disable that on all servers - I doubt anyone
has it on a workstation, either, but I don't have control over that.

Also, I've lied a bit, because I've been more than a bit distracted today...

There is a RAS Async Adapter that appears ghosted on each machine, but
I can't remove it - it says that it's necessary to boot the machine.

And, mea culpa, I tried again on all of the machines, and found that
there were two ghosted NICs on the VM in the US office, and
uninstalled them, but have not rebooted the US VM yet. That, so far,
hasn't solved the issue. I will see if I can reboot the VM in the US
office this evening. If that doesn't solve it, I will also change the
MAC address on the US VM, though as I've said before I don't see that
a duplicate MAC address on separate subnets should be a problem.

Kurt

On Mon, Nov 1, 2010 at 14:04, Miller Bonnie L.
 wrote:
> Have you checked WINS/Lmhosts for duplicates or static entries?
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Monday, November 01, 2010 1:54 PM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> BTW - I don't think I mentioned it, but all of the Windows boxes are
> Win2k3 R2 fully patched.
>
> On Mon, Nov 1, 2010 at 13:48, Kurt Buff  wrote:
>> Yup - no ghosted NICs.
>>
>> On Mon, Nov 1, 2010 at 13:39, Miller Bonnie L.
>>  wrote:
>>> Did you run the command sequence first?  You won't see them without doing 
>>> that.  Anything ghosted will have a bit of a grayed-out appearance:
>>>
>>> Run cmd as administrator and type
>>>        set devmgr_show_nonpresent_devices=1    
>>>        devmgmt.msc             
>>>
>>> When device manager opens, select to show hidden devices.
>>>
>>> -Bonnie
>>>
>>> -Original Message-
>>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>>> Sent: Monday, November 01, 2010 1:28 PM
>>> To: NT System Admin Issues
>>> Subject: Re: A real puzzler...
>>>
>>> Here's what I see so far today after going to the control panel and
>>> selecting "Show hidden devices" - I don't think I'm seeing any ghost
>>> NICs:
>>>
>>> DC in AU office (Dell 1850 - seems to be replying to ARP for
>>> 192.168.61.31, but is 192.168.61.30):
>>>   Direct Parallel
>>>   Intel(R) Pro/1000 MT Network Connection
>>>   Intel(R) Pro/1000 MT Network Connection #2 (disabled - this is the
>>> one that picked up a DHCP address when plugged in)
>>>   WAN Miniport (IP)
>>>   WAN Miniport (L2TP)
>>>   WAN Miniport (Network Monitor)
>>>   WAN Miniport (PPPOE)
>>>   WAN Miniport (PPTP)
>>>
>>> VM (on ESXi4 box) in AU office (refuses to accept 192.168.61.30, says
>>> another machine has IP address):
>>>   Direct Parallel
>>>   Intel(R) Pro/1000 MT Network Connection
>>>   WAN Miniport (IP)
>>>   WAN Miniport (L2TP)
>>>   WAN Miniport (Network Monitor)
>>>   WAN Miniport (PPPOE)
>>>   WAN Miniport (PPTP)
>>>
>>> VM (on ESX 3.5 box) in US office, has same MAC as DC in AU office.
>>> Address is 192.168.10.82, has never had a 61.0/24 address, and isn't
>>> seeing any ARP requests for it:
>>>   Direct Parallel
>>>   VMWare Accelerated AMD PCNet Adapter
>>>   WAN Miniport (IP)
>>>   WAN Miniport (L2TP)
>>>   WAN Miniport (Network Monitor)
>>>   WAN Miniport (PPPOE)
>>>   WAN Miniport (PPTP)
>>>
>>> I'm thinking of standing up a small XP VM, and assigning it the
>>> problematic address, and see who answers.
>>>
>>> Kurt
>>>
>>> On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  
>>> wrote:
>>>> Kurt -
>>>>
>>>> In device manager is an option to "show hidden devices". Enable that, both 
>>>> on the "new" server there and the "old" server there and see if you have a 
>>>> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem 
>>>> IP address.
>>>>
>>>> Remove the ghost NIC and you'll remove the problem.
>>>>
>>>> Regards,
>>>>
>>>> Michael B. Smith
>>>> Consultant and Exchange MVP
>>>> http://TheEssentialExchange.com
>>>>
>>>> 
>>&g

RE: A real puzzler...

2010-11-01 Thread Miller Bonnie L .

Have you checked WINS/Lmhosts for duplicates or static entries?

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Monday, November 01, 2010 1:54 PM
To: NT System Admin Issues
Subject: Re: A real puzzler...

BTW - I don't think I mentioned it, but all of the Windows boxes are
Win2k3 R2 fully patched.

On Mon, Nov 1, 2010 at 13:48, Kurt Buff  wrote:
> Yup - no ghosted NICs.
>
> On Mon, Nov 1, 2010 at 13:39, Miller Bonnie L.
>  wrote:
>> Did you run the command sequence first?  You won't see them without doing 
>> that.  Anything ghosted will have a bit of a grayed-out appearance:
>>
>> Run cmd as administrator and type
>>        set devmgr_show_nonpresent_devices=1    
>>        devmgmt.msc             
>>
>> When device manager opens, select to show hidden devices.
>>
>> -Bonnie
>>
>> -Original Message-
>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> Sent: Monday, November 01, 2010 1:28 PM
>> To: NT System Admin Issues
>> Subject: Re: A real puzzler...
>>
>> Here's what I see so far today after going to the control panel and
>> selecting "Show hidden devices" - I don't think I'm seeing any ghost
>> NICs:
>>
>> DC in AU office (Dell 1850 - seems to be replying to ARP for
>> 192.168.61.31, but is 192.168.61.30):
>>   Direct Parallel
>>   Intel(R) Pro/1000 MT Network Connection
>>   Intel(R) Pro/1000 MT Network Connection #2 (disabled - this is the
>> one that picked up a DHCP address when plugged in)
>>   WAN Miniport (IP)
>>   WAN Miniport (L2TP)
>>   WAN Miniport (Network Monitor)
>>   WAN Miniport (PPPOE)
>>   WAN Miniport (PPTP)
>>
>> VM (on ESXi4 box) in AU office (refuses to accept 192.168.61.30, says
>> another machine has IP address):
>>   Direct Parallel
>>   Intel(R) Pro/1000 MT Network Connection
>>   WAN Miniport (IP)
>>   WAN Miniport (L2TP)
>>   WAN Miniport (Network Monitor)
>>   WAN Miniport (PPPOE)
>>   WAN Miniport (PPTP)
>>
>> VM (on ESX 3.5 box) in US office, has same MAC as DC in AU office.
>> Address is 192.168.10.82, has never had a 61.0/24 address, and isn't
>> seeing any ARP requests for it:
>>   Direct Parallel
>>   VMWare Accelerated AMD PCNet Adapter
>>   WAN Miniport (IP)
>>   WAN Miniport (L2TP)
>>   WAN Miniport (Network Monitor)
>>   WAN Miniport (PPPOE)
>>   WAN Miniport (PPTP)
>>
>> I'm thinking of standing up a small XP VM, and assigning it the
>> problematic address, and see who answers.
>>
>> Kurt
>>
>> On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  
>> wrote:
>>> Kurt -
>>>
>>> In device manager is an option to "show hidden devices". Enable that, both 
>>> on the "new" server there and the "old" server there and see if you have a 
>>> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP 
>>> address.
>>>
>>> Remove the ghost NIC and you'll remove the problem.
>>>
>>> Regards,
>>>
>>> Michael B. Smith
>>> Consultant and Exchange MVP
>>> http://TheEssentialExchange.com
>>>
>>> ________
>>> From: Ralph Smith [...@gatewayindustries.org]
>>> Sent: Saturday, October 30, 2010 12:22 PM
>>> To: NT System Admin Issues
>>> Subject: RE: A real puzzler...
>>>
>>> Do you have an AV application on the server?  The reason I ask is I had
>>> some servers that exibited the exact symptoms you are describing after
>>> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>>> Sent: Saturday, October 30, 2010 1:49 AM
>>> To: NT System Admin Issues
>>> Subject: A real puzzler...
>>>
>>> All,
>>>
>>> I'm in the US, and have a problem in our AU office that I'm having
>>> difficulty wrapping my brain around. I have a theory, but it is still a
>>> strange situation, and any feedback anyone can provide would be
>>> appreciated.
>>>
>>> The AU office has a server, which I've just recently stood up, using an
>>> address assigned by DHCP. This is not ideal, obviously, but the thing
>>> refuses to take the static IP address that it's slated to get
>>> (192.168.61.30.) It's a VM on a new ESXi server.
>>>
>

Re: A real puzzler...

2010-11-01 Thread Kurt Buff

BTW - I don't think I mentioned it, but all of the Windows boxes are
Win2k3 R2 fully patched.

On Mon, Nov 1, 2010 at 13:48, Kurt Buff  wrote:
> Yup - no ghosted NICs.
>
> On Mon, Nov 1, 2010 at 13:39, Miller Bonnie L.
>  wrote:
>> Did you run the command sequence first?  You won't see them without doing 
>> that.  Anything ghosted will have a bit of a grayed-out appearance:
>>
>> Run cmd as administrator and type
>>        set devmgr_show_nonpresent_devices=1    
>>        devmgmt.msc             
>>
>> When device manager opens, select to show hidden devices.
>>
>> -Bonnie
>>
>> -Original Message-
>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> Sent: Monday, November 01, 2010 1:28 PM
>> To: NT System Admin Issues
>> Subject: Re: A real puzzler...
>>
>> Here's what I see so far today after going to the control panel and
>> selecting "Show hidden devices" - I don't think I'm seeing any ghost
>> NICs:
>>
>> DC in AU office (Dell 1850 - seems to be replying to ARP for
>> 192.168.61.31, but is 192.168.61.30):
>>   Direct Parallel
>>   Intel(R) Pro/1000 MT Network Connection
>>   Intel(R) Pro/1000 MT Network Connection #2 (disabled - this is the
>> one that picked up a DHCP address when plugged in)
>>   WAN Miniport (IP)
>>   WAN Miniport (L2TP)
>>   WAN Miniport (Network Monitor)
>>   WAN Miniport (PPPOE)
>>   WAN Miniport (PPTP)
>>
>> VM (on ESXi4 box) in AU office (refuses to accept 192.168.61.30, says
>> another machine has IP address):
>>   Direct Parallel
>>   Intel(R) Pro/1000 MT Network Connection
>>   WAN Miniport (IP)
>>   WAN Miniport (L2TP)
>>   WAN Miniport (Network Monitor)
>>   WAN Miniport (PPPOE)
>>   WAN Miniport (PPTP)
>>
>> VM (on ESX 3.5 box) in US office, has same MAC as DC in AU office.
>> Address is 192.168.10.82, has never had a 61.0/24 address, and isn't
>> seeing any ARP requests for it:
>>   Direct Parallel
>>   VMWare Accelerated AMD PCNet Adapter
>>   WAN Miniport (IP)
>>   WAN Miniport (L2TP)
>>   WAN Miniport (Network Monitor)
>>   WAN Miniport (PPPOE)
>>   WAN Miniport (PPTP)
>>
>> I'm thinking of standing up a small XP VM, and assigning it the
>> problematic address, and see who answers.
>>
>> Kurt
>>
>> On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  
>> wrote:
>>> Kurt -
>>>
>>> In device manager is an option to "show hidden devices". Enable that, both 
>>> on the "new" server there and the "old" server there and see if you have a 
>>> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP 
>>> address.
>>>
>>> Remove the ghost NIC and you'll remove the problem.
>>>
>>> Regards,
>>>
>>> Michael B. Smith
>>> Consultant and Exchange MVP
>>> http://TheEssentialExchange.com
>>>
>>> ________
>>> From: Ralph Smith [...@gatewayindustries.org]
>>> Sent: Saturday, October 30, 2010 12:22 PM
>>> To: NT System Admin Issues
>>> Subject: RE: A real puzzler...
>>>
>>> Do you have an AV application on the server?  The reason I ask is I had
>>> some servers that exibited the exact symptoms you are describing after
>>> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>>> Sent: Saturday, October 30, 2010 1:49 AM
>>> To: NT System Admin Issues
>>> Subject: A real puzzler...
>>>
>>> All,
>>>
>>> I'm in the US, and have a problem in our AU office that I'm having
>>> difficulty wrapping my brain around. I have a theory, but it is still a
>>> strange situation, and any feedback anyone can provide would be
>>> appreciated.
>>>
>>> The AU office has a server, which I've just recently stood up, using an
>>> address assigned by DHCP. This is not ideal, obviously, but the thing
>>> refuses to take the static IP address that it's slated to get
>>> (192.168.61.30.) It's a VM on a new ESXi server.
>>>
>>> When I try to assign it the static address, it keeps getting an error
>>> message that another machine has the address.
>>>
>>> However, when I ping the IP address that the machine refuses to use, I

Re: A real puzzler...

2010-11-01 Thread Kurt Buff

Yup - no ghosted NICs.

On Mon, Nov 1, 2010 at 13:39, Miller Bonnie L.
 wrote:
> Did you run the command sequence first?  You won't see them without doing 
> that.  Anything ghosted will have a bit of a grayed-out appearance:
>
> Run cmd as administrator and type
>        set devmgr_show_nonpresent_devices=1    
>        devmgmt.msc             
>
> When device manager opens, select to show hidden devices.
>
> -Bonnie
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Monday, November 01, 2010 1:28 PM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> Here's what I see so far today after going to the control panel and
> selecting "Show hidden devices" - I don't think I'm seeing any ghost
> NICs:
>
> DC in AU office (Dell 1850 - seems to be replying to ARP for
> 192.168.61.31, but is 192.168.61.30):
>   Direct Parallel
>   Intel(R) Pro/1000 MT Network Connection
>   Intel(R) Pro/1000 MT Network Connection #2 (disabled - this is the
> one that picked up a DHCP address when plugged in)
>   WAN Miniport (IP)
>   WAN Miniport (L2TP)
>   WAN Miniport (Network Monitor)
>   WAN Miniport (PPPOE)
>   WAN Miniport (PPTP)
>
> VM (on ESXi4 box) in AU office (refuses to accept 192.168.61.30, says
> another machine has IP address):
>   Direct Parallel
>   Intel(R) Pro/1000 MT Network Connection
>   WAN Miniport (IP)
>   WAN Miniport (L2TP)
>   WAN Miniport (Network Monitor)
>   WAN Miniport (PPPOE)
>   WAN Miniport (PPTP)
>
> VM (on ESX 3.5 box) in US office, has same MAC as DC in AU office.
> Address is 192.168.10.82, has never had a 61.0/24 address, and isn't
> seeing any ARP requests for it:
>   Direct Parallel
>   VMWare Accelerated AMD PCNet Adapter
>   WAN Miniport (IP)
>   WAN Miniport (L2TP)
>   WAN Miniport (Network Monitor)
>   WAN Miniport (PPPOE)
>   WAN Miniport (PPTP)
>
> I'm thinking of standing up a small XP VM, and assigning it the
> problematic address, and see who answers.
>
> Kurt
>
> On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  wrote:
>> Kurt -
>>
>> In device manager is an option to "show hidden devices". Enable that, both 
>> on the "new" server there and the "old" server there and see if you have a 
>> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP 
>> address.
>>
>> Remove the ghost NIC and you'll remove the problem.
>>
>> Regards,
>>
>> Michael B. Smith
>> Consultant and Exchange MVP
>> http://TheEssentialExchange.com
>>
>> 
>> From: Ralph Smith [...@gatewayindustries.org]
>> Sent: Saturday, October 30, 2010 12:22 PM
>> To: NT System Admin Issues
>> Subject: RE: A real puzzler...
>>
>> Do you have an AV application on the server?  The reason I ask is I had
>> some servers that exibited the exact symptoms you are describing after
>> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>>
>>
>>
>>
>> -Original Message-
>> From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> Sent: Saturday, October 30, 2010 1:49 AM
>> To: NT System Admin Issues
>> Subject: A real puzzler...
>>
>> All,
>>
>> I'm in the US, and have a problem in our AU office that I'm having
>> difficulty wrapping my brain around. I have a theory, but it is still a
>> strange situation, and any feedback anyone can provide would be
>> appreciated.
>>
>> The AU office has a server, which I've just recently stood up, using an
>> address assigned by DHCP. This is not ideal, obviously, but the thing
>> refuses to take the static IP address that it's slated to get
>> (192.168.61.30.) It's a VM on a new ESXi server.
>>
>> When I try to assign it the static address, it keeps getting an error
>> message that another machine has the address.
>>
>> However, when I ping the IP address that the machine refuses to use, I
>> get no answer.
>>
>> When I use netmon on the VM in the AU office to capture ARP traffic, I
>> get a MAC address that's for the DC. However, the DC has never had
>> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>>
>> I've even fired up regedit on the DC to search for the IP address, and
>> all I'm showing is the one it's supposed to have - 192.168.61.31
>>
>> I'm more than a little baffled by this one.
>>
>> One thing I should note, just because: The DC in the AU office is a
>&g

RE: A real puzzler...

2010-11-01 Thread Miller Bonnie L .

Did you run the command sequence first?  You won't see them without doing that. 
 Anything ghosted will have a bit of a grayed-out appearance:

Run cmd as administrator and type
set devmgr_show_nonpresent_devices=1
devmgmt.msc 

When device manager opens, select to show hidden devices.

-Bonnie

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Monday, November 01, 2010 1:28 PM
To: NT System Admin Issues
Subject: Re: A real puzzler...

Here's what I see so far today after going to the control panel and
selecting "Show hidden devices" - I don't think I'm seeing any ghost
NICs:

DC in AU office (Dell 1850 - seems to be replying to ARP for
192.168.61.31, but is 192.168.61.30):
   Direct Parallel
   Intel(R) Pro/1000 MT Network Connection
   Intel(R) Pro/1000 MT Network Connection #2 (disabled - this is the
one that picked up a DHCP address when plugged in)
   WAN Miniport (IP)
   WAN Miniport (L2TP)
   WAN Miniport (Network Monitor)
   WAN Miniport (PPPOE)
   WAN Miniport (PPTP)

VM (on ESXi4 box) in AU office (refuses to accept 192.168.61.30, says
another machine has IP address):
   Direct Parallel
   Intel(R) Pro/1000 MT Network Connection
   WAN Miniport (IP)
   WAN Miniport (L2TP)
   WAN Miniport (Network Monitor)
   WAN Miniport (PPPOE)
   WAN Miniport (PPTP)

VM (on ESX 3.5 box) in US office, has same MAC as DC in AU office.
Address is 192.168.10.82, has never had a 61.0/24 address, and isn't
seeing any ARP requests for it:
   Direct Parallel
   VMWare Accelerated AMD PCNet Adapter
   WAN Miniport (IP)
   WAN Miniport (L2TP)
   WAN Miniport (Network Monitor)
   WAN Miniport (PPPOE)
   WAN Miniport (PPTP)

I'm thinking of standing up a small XP VM, and assigning it the
problematic address, and see who answers.

Kurt

On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  wrote:
> Kurt -
>
> In device manager is an option to "show hidden devices". Enable that, both on 
> the "new" server there and the "old" server there and see if you have a 
> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP 
> address.
>
> Remove the ghost NIC and you'll remove the problem.
>
> Regards,
>
> Michael B. Smith
> Consultant and Exchange MVP
> http://TheEssentialExchange.com
>
> 
> From: Ralph Smith [...@gatewayindustries.org]
> Sent: Saturday, October 30, 2010 12:22 PM
> To: NT System Admin Issues
> Subject: RE: A real puzzler...
>
> Do you have an AV application on the server?  The reason I ask is I had
> some servers that exibited the exact symptoms you are describing after
> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>
>
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, October 30, 2010 1:49 AM
> To: NT System Admin Issues
> Subject: A real puzzler...
>
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having
> difficulty wrapping my brain around. I have a theory, but it is still a
> strange situation, and any feedback anyone can provide would be
> appreciated.
>
> The AU office has a server, which I've just recently stood up, using an
> address assigned by DHCP. This is not ideal, obviously, but the thing
> refuses to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error
> message that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I
> get no answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a
> machine that had been used in the US office about two years ago. We did
> a P2V on it, and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have expected
> the the MAC to change when it got the virtual NIC), but AFAICT this
> shouldn't make a difference, since they are in different subnets
> entirely, with different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsof

Re: A real puzzler...

2010-11-01 Thread Kurt Buff

Here's what I see so far today after going to the control panel and
selecting "Show hidden devices" - I don't think I'm seeing any ghost
NICs:

DC in AU office (Dell 1850 - seems to be replying to ARP for
192.168.61.31, but is 192.168.61.30):
   Direct Parallel
   Intel(R) Pro/1000 MT Network Connection
   Intel(R) Pro/1000 MT Network Connection #2 (disabled - this is the
one that picked up a DHCP address when plugged in)
   WAN Miniport (IP)
   WAN Miniport (L2TP)
   WAN Miniport (Network Monitor)
   WAN Miniport (PPPOE)
   WAN Miniport (PPTP)

VM (on ESXi4 box) in AU office (refuses to accept 192.168.61.30, says
another machine has IP address):
   Direct Parallel
   Intel(R) Pro/1000 MT Network Connection
   WAN Miniport (IP)
   WAN Miniport (L2TP)
   WAN Miniport (Network Monitor)
   WAN Miniport (PPPOE)
   WAN Miniport (PPTP)

VM (on ESX 3.5 box) in US office, has same MAC as DC in AU office.
Address is 192.168.10.82, has never had a 61.0/24 address, and isn't
seeing any ARP requests for it:
   Direct Parallel
   VMWare Accelerated AMD PCNet Adapter
   WAN Miniport (IP)
   WAN Miniport (L2TP)
   WAN Miniport (Network Monitor)
   WAN Miniport (PPPOE)
   WAN Miniport (PPTP)

I'm thinking of standing up a small XP VM, and assigning it the
problematic address, and see who answers.

Kurt

On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  wrote:
> Kurt -
>
> In device manager is an option to "show hidden devices". Enable that, both on 
> the "new" server there and the "old" server there and see if you have a 
> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP 
> address.
>
> Remove the ghost NIC and you'll remove the problem.
>
> Regards,
>
> Michael B. Smith
> Consultant and Exchange MVP
> http://TheEssentialExchange.com
>
> 
> From: Ralph Smith [...@gatewayindustries.org]
> Sent: Saturday, October 30, 2010 12:22 PM
> To: NT System Admin Issues
> Subject: RE: A real puzzler...
>
> Do you have an AV application on the server?  The reason I ask is I had
> some servers that exibited the exact symptoms you are describing after
> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>
>
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, October 30, 2010 1:49 AM
> To: NT System Admin Issues
> Subject: A real puzzler...
>
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having
> difficulty wrapping my brain around. I have a theory, but it is still a
> strange situation, and any feedback anyone can provide would be
> appreciated.
>
> The AU office has a server, which I've just recently stood up, using an
> address assigned by DHCP. This is not ideal, obviously, but the thing
> refuses to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error
> message that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I
> get no answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a
> machine that had been used in the US office about two years ago. We did
> a P2V on it, and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have expected
> the the MAC to change when it got the virtual NIC), but AFAICT this
> shouldn't make a difference, since they are in different subnets
> entirely, with different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
> Confidentiality Notice:
>
> --
>
>
>
> This communication, including any attachments, may contain confidential 
> information and is intended only for the individual or entity to whom it

Re: A real puzzler...

2010-11-01 Thread Kurt Buff

No Apple, but there are a few Win7 machines, and some Linux machines.

On Mon, Nov 1, 2010 at 12:30, Jon Harris  wrote:
> I have seen this with both Apple and Win 7 products taking an IP and because
> of the way the firewall was configured not responding to ping's or several
> other products.  I was only able to trace it back to a machine by killing
> switch ports one at a time and resetting DHCP until the offending machine
> was off the network.  There had to be an easier way but I was at the time
> just in too much of a hurry to get the job done to look another way.
>
> Just for your info/laugh the the Win 7 machine was the management system and
> took the least amount of time to find.  I was moving it from one subnet to
> another then remoting back in and "discovered" that I had no problem.  Put
> that machine back in the original subnet and problem came back.
>
>
> Jon
>
> On Sun, Oct 31, 2010 at 8:35 PM, Kurt Buff  wrote:
>>
>> The VM I'm standing up gets the error message that another machine has
>> the IP address. The machine that seems to be responding is the DC.
>>
>> On Sat, Oct 30, 2010 at 23:09, Ken Schaefer  wrote:
>> > Is the error that another machine has the IP address?
>> > Or is the error that another NIC in the machine has the same IP address?
>> >
>> > Slightly different errors, but the later usually means you have a hidden
>> > NIC. The former means some other machine has the IP. You can also get 
>> > around
>> > the latter error by unchecking the "validate configuration" checkbox.
>> >
>> > Cheers
>> > Ken
>> >
>> > -Original Message-
>> > From: Kurt Buff [mailto:kurt.b...@gmail.com]
>> > Sent: Sunday, 31 October 2010 8:27 AM
>> > To: NT System Admin Issues
>> > Subject: Re: A real puzzler...
>> >
>> > On Sat, Oct 30, 2010 at 17:23, Ben Scott  wrote:
>> >> On Sat, Oct 30, 2010 at 7:01 PM, Kurt Buff  wrote:
>> >>> I will try those commands, but can't really shut down the DC in the
>> >>> AU office - I don't have a way to start it remotely.
>> >>
>> >>  Sure you do.  You phone the guys in the AU office and have them hit
>> >> the power button.  HHOS.
>> >>
>> >>  Or, if it's a managed switch, you could disable the switch port.
>> >> Or, wait, didn't you say it's a VM?  Does your VM system have a way to
>> >> disable the virtual switch port?
>> >>
>> >>  I'd try the Dev Mgr idea someone else posted first, of course.  :)
>> >>
>> >> -- Ben
>> >
>> > The DC is not a VM - the machine that refuses the IP address is the VM.
>> >
>> > I'll try the other stuff first...
>> >
>> > Kurt
>> >
>> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>> >
>> > ---
>> > To manage subscriptions click here:
>> > http://lyris.sunbelt-software.com/read/my_forums/
>> > or send an email to listmana...@lyris.sunbeltsoftware.com
>> > with the body: unsubscribe ntsysadmin
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>
>> ---
>> To manage subscriptions click here:
>> http://lyris.sunbelt-software.com/read/my_forums/
>> or send an email to listmana...@lyris.sunbeltsoftware.com
>> with the body: unsubscribe ntsysadmin
>>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-11-01 Thread Jon Harris

I have seen this with both Apple and Win 7 products taking an IP and because
of the way the firewall was configured not responding to ping's or several
other products.  I was only able to trace it back to a machine by killing
switch ports one at a time and resetting DHCP until the offending machine
was off the network.  There had to be an easier way but I was at the time
just in too much of a hurry to get the job done to look another way.

Just for your info/laugh the the Win 7 machine was the management system and
took the least amount of time to find.  I was moving it from one subnet to
another then remoting back in and "discovered" that I had no problem.  Put
that machine back in the original subnet and problem came back.


Jon

On Sun, Oct 31, 2010 at 8:35 PM, Kurt Buff  wrote:

> The VM I'm standing up gets the error message that another machine has
> the IP address. The machine that seems to be responding is the DC.
>
> On Sat, Oct 30, 2010 at 23:09, Ken Schaefer  wrote:
> > Is the error that another machine has the IP address?
> > Or is the error that another NIC in the machine has the same IP address?
> >
> > Slightly different errors, but the later usually means you have a hidden
> NIC. The former means some other machine has the IP. You can also get around
> the latter error by unchecking the "validate configuration" checkbox.
> >
> > Cheers
> > Ken
> >
> > -Original Message-
> > From: Kurt Buff [mailto:kurt.b...@gmail.com]
> > Sent: Sunday, 31 October 2010 8:27 AM
> > To: NT System Admin Issues
> > Subject: Re: A real puzzler...
> >
> > On Sat, Oct 30, 2010 at 17:23, Ben Scott  wrote:
> >> On Sat, Oct 30, 2010 at 7:01 PM, Kurt Buff  wrote:
> >>> I will try those commands, but can't really shut down the DC in the
> >>> AU office - I don't have a way to start it remotely.
> >>
> >>  Sure you do.  You phone the guys in the AU office and have them hit
> >> the power button.  HHOS.
> >>
> >>  Or, if it's a managed switch, you could disable the switch port.
> >> Or, wait, didn't you say it's a VM?  Does your VM system have a way to
> >> disable the virtual switch port?
> >>
> >>  I'd try the Dev Mgr idea someone else posted first, of course.  :)
> >>
> >> -- Ben
> >
> > The DC is not a VM - the machine that refuses the IP address is the VM.
> >
> > I'll try the other stuff first...
> >
> > Kurt
> >
> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
> >
> > ---
> > To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> > or send an email to listmana...@lyris.sunbeltsoftware.com
> > with the body: unsubscribe ntsysadmin
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-31 Thread Kurt Buff

The VM I'm standing up gets the error message that another machine has
the IP address. The machine that seems to be responding is the DC.

On Sat, Oct 30, 2010 at 23:09, Ken Schaefer  wrote:
> Is the error that another machine has the IP address?
> Or is the error that another NIC in the machine has the same IP address?
>
> Slightly different errors, but the later usually means you have a hidden NIC. 
> The former means some other machine has the IP. You can also get around the 
> latter error by unchecking the "validate configuration" checkbox.
>
> Cheers
> Ken
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Sunday, 31 October 2010 8:27 AM
> To: NT System Admin Issues
> Subject: Re: A real puzzler...
>
> On Sat, Oct 30, 2010 at 17:23, Ben Scott  wrote:
>> On Sat, Oct 30, 2010 at 7:01 PM, Kurt Buff  wrote:
>>> I will try those commands, but can't really shut down the DC in the
>>> AU office - I don't have a way to start it remotely.
>>
>>  Sure you do.  You phone the guys in the AU office and have them hit
>> the power button.  HHOS.
>>
>>  Or, if it's a managed switch, you could disable the switch port.
>> Or, wait, didn't you say it's a VM?  Does your VM system have a way to
>> disable the virtual switch port?
>>
>>  I'd try the Dev Mgr idea someone else posted first, of course.  :)
>>
>> -- Ben
>
> The DC is not a VM - the machine that refuses the IP address is the VM.
>
> I'll try the other stuff first...
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

RE: A real puzzler...

2010-10-30 Thread Ken Schaefer

Is the error that another machine has the IP address?
Or is the error that another NIC in the machine has the same IP address?

Slightly different errors, but the later usually means you have a hidden NIC. 
The former means some other machine has the IP. You can also get around the 
latter error by unchecking the "validate configuration" checkbox.

Cheers
Ken

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Sunday, 31 October 2010 8:27 AM
To: NT System Admin Issues
Subject: Re: A real puzzler...

On Sat, Oct 30, 2010 at 17:23, Ben Scott  wrote:
> On Sat, Oct 30, 2010 at 7:01 PM, Kurt Buff  wrote:
>> I will try those commands, but can't really shut down the DC in the 
>> AU office - I don't have a way to start it remotely.
>
>  Sure you do.  You phone the guys in the AU office and have them hit 
> the power button.  HHOS.
>
>  Or, if it's a managed switch, you could disable the switch port.
> Or, wait, didn't you say it's a VM?  Does your VM system have a way to 
> disable the virtual switch port?
>
>  I'd try the Dev Mgr idea someone else posted first, of course.  :)
>
> -- Ben

The DC is not a VM - the machine that refuses the IP address is the VM.

I'll try the other stuff first...

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Kurt Buff

On Sat, Oct 30, 2010 at 17:23, Ben Scott  wrote:
> On Sat, Oct 30, 2010 at 7:01 PM, Kurt Buff  wrote:
>> I will try those commands, but can't really shut down the DC in the AU
>> office - I don't have a way to start it remotely.
>
>  Sure you do.  You phone the guys in the AU office and have them hit
> the power button.  HHOS.
>
>  Or, if it's a managed switch, you could disable the switch port.
> Or, wait, didn't you say it's a VM?  Does your VM system have a way to
> disable the virtual switch port?
>
>  I'd try the Dev Mgr idea someone else posted first, of course.  :)
>
> -- Ben

The DC is not a VM - the machine that refuses the IP address is the VM.

I'll try the other stuff first...

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Ben Scott

On Sat, Oct 30, 2010 at 7:01 PM, Kurt Buff  wrote:
> I will try those commands, but can't really shut down the DC in the AU
> office - I don't have a way to start it remotely.

  Sure you do.  You phone the guys in the AU office and have them hit
the power button.  HHOS.

  Or, if it's a managed switch, you could disable the switch port.
Or, wait, didn't you say it's a VM?  Does your VM system have a way to
disable the virtual switch port?

  I'd try the Dev Mgr idea someone else posted first, of course.  :)

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Kurt Buff

Excellent thought. I will do that.

Kurt

On Sat, Oct 30, 2010 at 09:26, Michael B. Smith  wrote:
> Kurt -
>
> In device manager is an option to "show hidden devices". Enable that, both on 
> the "new" server there and the "old" server there and see if you have a 
> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP 
> address.
>
> Remove the ghost NIC and you'll remove the problem.
>
> Regards,
>
> Michael B. Smith
> Consultant and Exchange MVP
> http://TheEssentialExchange.com
>
> 
> From: Ralph Smith [...@gatewayindustries.org]
> Sent: Saturday, October 30, 2010 12:22 PM
> To: NT System Admin Issues
> Subject: RE: A real puzzler...
>
> Do you have an AV application on the server?  The reason I ask is I had
> some servers that exibited the exact symptoms you are describing after
> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>
>
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, October 30, 2010 1:49 AM
> To: NT System Admin Issues
> Subject: A real puzzler...
>
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having
> difficulty wrapping my brain around. I have a theory, but it is still a
> strange situation, and any feedback anyone can provide would be
> appreciated.
>
> The AU office has a server, which I've just recently stood up, using an
> address assigned by DHCP. This is not ideal, obviously, but the thing
> refuses to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error
> message that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I
> get no answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a
> machine that had been used in the US office about two years ago. We did
> a P2V on it, and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have expected
> the the MAC to change when it got the virtual NIC), but AFAICT this
> shouldn't make a difference, since they are in different subnets
> entirely, with different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
> Confidentiality Notice:
>
> --
>
>
>
> This communication, including any attachments, may contain confidential 
> information and is intended only for the individual or entity to whom it is 
> addressed. Any review, dissemination, or copying of this communication by 
> anyone other than the intended recipient is strictly prohibited. If you are 
> not the intended recipient, please contact the sender by reply email, delete 
> and destroy all copies of the original message.
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Kurt Buff

Nope - no AV yet. Too new. I haven't finished installing the apps yet.

On Sat, Oct 30, 2010 at 09:22, Ralph Smith  wrote:
> Do you have an AV application on the server?  The reason I ask is I had
> some servers that exibited the exact symptoms you are describing after
> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>
>
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, October 30, 2010 1:49 AM
> To: NT System Admin Issues
> Subject: A real puzzler...
>
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having
> difficulty wrapping my brain around. I have a theory, but it is still a
> strange situation, and any feedback anyone can provide would be
> appreciated.
>
> The AU office has a server, which I've just recently stood up, using an
> address assigned by DHCP. This is not ideal, obviously, but the thing
> refuses to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error
> message that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I
> get no answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a
> machine that had been used in the US office about two years ago. We did
> a P2V on it, and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have expected
> the the MAC to change when it got the virtual NIC), but AFAICT this
> shouldn't make a difference, since they are in different subnets
> entirely, with different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
> Confidentiality Notice:
>
> --
>
>
>
> This communication, including any attachments, may contain confidential 
> information and is intended only for the individual or entity to whom it is 
> addressed. Any review, dissemination, or copying of this communication by 
> anyone other than the intended recipient is strictly prohibited. If you are 
> not the intended recipient, please contact the sender by reply email, delete 
> and destroy all copies of the original message.
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Kurt Buff

That's worth a shot.

On Sat, Oct 30, 2010 at 00:36, Blackman, Woody  wrote:
> If the error is on the VM Guest, it could be a ghosted NIC from the P2V
>
> To work around this behavior and display phantom devices when you use the 
> Show hidden devices command:
>
> Click Start, click Run, type cmd.exe, and then press ENTER.
> Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
> Type Start DEVMGMT.MSC, and then press ENTER.
> Click View, and then click Show Hidden Devices.
> Expand the Network Adapters tree.
> Right-click the dimmed network adapter, and then click Uninstall.
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Friday, October 29, 2010 10:49 PM
> To: NT System Admin Issues
> Subject: A real puzzler...
>
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having difficulty 
> wrapping my brain around. I have a theory, but it is still a strange 
> situation, and any feedback anyone can provide would be appreciated.
>
> The AU office has a server, which I've just recently stood up, using an 
> address assigned by DHCP. This is not ideal, obviously, but the thing refuses 
> to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error message 
> that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I get no 
> answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I get a 
> MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and all 
> I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a machine 
> that had been used in the US office about two years ago. We did a P2V on it, 
> and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have expected the 
> the MAC to change when it got the virtual NIC), but AFAICT this shouldn't 
> make a difference, since they are in different subnets entirely, with 
> different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Kurt Buff

On Fri, Oct 29, 2010 at 23:24, Ben Scott  wrote:
> On Sat, Oct 30, 2010 at 1:49 AM, Kurt Buff  wrote:
>> I'm more than a little baffled by this one.
>
>  It does sound weird.  Random thoughts follow, no particular order,
> sleep-deprived brain, so use at your own risk.  :)

Understood...

>> However, when I ping the IP address that the machine refuses to use, I
>> get no answer.
>
>  Maybe try nmap with a full port scan, see if anything else comes back?

I tried angry IP scanner - not as god as nmap, but didn't get anything.

>> When I use netmon on the VM in the AU office to capture ARP traffic, I
>> get a MAC address that's for the DC.
>
>  Do you see anything else for that IP address besides an ARP "is-at" message?

Nothing...

>> I've even fired up regedit on the DC to search for the IP address, and
>> all I'm showing is the one it's supposed to have - 192.168.61.31
>
>  There are other ways to store IP addresses (e.g., binary data, or
> outside the registry entirely), so that's not entirely conclusive.
>
>  On the DC, check RRAS (Routing and Remote Access), see if .30 is
> configured for dial-in or something like that.
>
>  Check the following on the DC for clues:
>
> getmac
> ipconfig /all
> netsh -c interface show interface
> netsh -c interface show alias
>
>  Can you temporarily shut down the misbehaving DC (or disable its
> switch port) and see if the ARP still comes back?  Long shot, but
> maybe something's spoofing it.

I will try those commands, but can't really shut down the DC in the AU
office - I don't have a way to start it remotely.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-30 Thread Micheal Espinola Jr

Niiice...  I haven't thought of that one in a really long time, but I
remember encountering similar the hard-way!

--
ME2







On Sat, Oct 30, 2010 at 9:26 AM, Michael B. Smith wrote:

> Kurt -
>
> In device manager is an option to "show hidden devices". Enable that, both
> on the "new" server there and the "old" server there and see if you have a
> "ghost" NIC. I bet you will. And that ghost NIC probably has the problem IP
> address.
>
> Remove the ghost NIC and you'll remove the problem.
>
> Regards,
>
> Michael B. Smith
> Consultant and Exchange MVP
> http://TheEssentialExchange.com
>
> 
> From: Ralph Smith [...@gatewayindustries.org]
> Sent: Saturday, October 30, 2010 12:22 PM
> To: NT System Admin Issues
> Subject: RE: A real puzzler...
>
> Do you have an AV application on the server?  The reason I ask is I had
> some servers that exibited the exact symptoms you are describing after
> installing VIPRE Premium on them.  Removing VIPRE solved the problem.
>
>
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, October 30, 2010 1:49 AM
> To: NT System Admin Issues
> Subject: A real puzzler...
>
> All,
>
> I'm in the US, and have a problem in our AU office that I'm having
> difficulty wrapping my brain around. I have a theory, but it is still a
> strange situation, and any feedback anyone can provide would be
> appreciated.
>
> The AU office has a server, which I've just recently stood up, using an
> address assigned by DHCP. This is not ideal, obviously, but the thing
> refuses to take the static IP address that it's slated to get
> (192.168.61.30.) It's a VM on a new ESXi server.
>
> When I try to assign it the static address, it keeps getting an error
> message that another machine has the address.
>
> However, when I ping the IP address that the machine refuses to use, I
> get no answer.
>
> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC. However, the DC has never had
> 192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.
>
> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31
>
> I'm more than a little baffled by this one.
>
> One thing I should note, just because: The DC in the AU office is a
> machine that had been used in the US office about two years ago. We did
> a P2V on it, and the VM from that still lives on in the US office.
> They do share a MAC address (I don't know why, as I would have expected
> the the MAC to change when it got the virtual NIC), but AFAICT this
> shouldn't make a difference, since they are in different subnets
> entirely, with different addresses.
>
> Anyone have thoughts on this?
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
> Confidentiality Notice:
>
> --
>
>
>
> This communication, including any attachments, may contain confidential
> information and is intended only for the individual or entity to whom it is
> addressed. Any review, dissemination, or copying of this communication by
> anyone other than the intended recipient is strictly prohibited. If you are
> not the intended recipient, please contact the sender by reply email, delete
> and destroy all copies of the original message.
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

RE: A real puzzler...

2010-10-30 Thread Michael B. Smith

Kurt -

In device manager is an option to "show hidden devices". Enable that, both on 
the "new" server there and the "old" server there and see if you have a "ghost" 
NIC. I bet you will. And that ghost NIC probably has the problem IP address.

Remove the ghost NIC and you'll remove the problem.

Regards,

Michael B. Smith
Consultant and Exchange MVP
http://TheEssentialExchange.com


From: Ralph Smith [...@gatewayindustries.org]
Sent: Saturday, October 30, 2010 12:22 PM
To: NT System Admin Issues
Subject: RE: A real puzzler...

Do you have an AV application on the server?  The reason I ask is I had
some servers that exibited the exact symptoms you are describing after
installing VIPRE Premium on them.  Removing VIPRE solved the problem.




-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com]
Sent: Saturday, October 30, 2010 1:49 AM
To: NT System Admin Issues
Subject: A real puzzler...

All,

I'm in the US, and have a problem in our AU office that I'm having
difficulty wrapping my brain around. I have a theory, but it is still a
strange situation, and any feedback anyone can provide would be
appreciated.

The AU office has a server, which I've just recently stood up, using an
address assigned by DHCP. This is not ideal, obviously, but the thing
refuses to take the static IP address that it's slated to get
(192.168.61.30.) It's a VM on a new ESXi server.

When I try to assign it the static address, it keeps getting an error
message that another machine has the address.

However, when I ping the IP address that the machine refuses to use, I
get no answer.

When I use netmon on the VM in the AU office to capture ARP traffic, I
get a MAC address that's for the DC. However, the DC has never had
192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.

I've even fired up regedit on the DC to search for the IP address, and
all I'm showing is the one it's supposed to have - 192.168.61.31

I'm more than a little baffled by this one.

One thing I should note, just because: The DC in the AU office is a
machine that had been used in the US office about two years ago. We did
a P2V on it, and the VM from that still lives on in the US office.
They do share a MAC address (I don't know why, as I would have expected
the the MAC to change when it got the virtual NIC), but AFAICT this
shouldn't make a difference, since they are in different subnets
entirely, with different addresses.

Anyone have thoughts on this?

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin
Confidentiality Notice:

--



This communication, including any attachments, may contain confidential 
information and is intended only for the individual or entity to whom it is 
addressed. Any review, dissemination, or copying of this communication by 
anyone other than the intended recipient is strictly prohibited. If you are not 
the intended recipient, please contact the sender by reply email, delete and 
destroy all copies of the original message.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

RE: A real puzzler...

2010-10-30 Thread Ralph Smith

Do you have an AV application on the server?  The reason I ask is I had
some servers that exibited the exact symptoms you are describing after
installing VIPRE Premium on them.  Removing VIPRE solved the problem.




-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Saturday, October 30, 2010 1:49 AM
To: NT System Admin Issues
Subject: A real puzzler...

All,

I'm in the US, and have a problem in our AU office that I'm having
difficulty wrapping my brain around. I have a theory, but it is still a
strange situation, and any feedback anyone can provide would be
appreciated.

The AU office has a server, which I've just recently stood up, using an
address assigned by DHCP. This is not ideal, obviously, but the thing
refuses to take the static IP address that it's slated to get
(192.168.61.30.) It's a VM on a new ESXi server.

When I try to assign it the static address, it keeps getting an error
message that another machine has the address.

However, when I ping the IP address that the machine refuses to use, I
get no answer.

When I use netmon on the VM in the AU office to capture ARP traffic, I
get a MAC address that's for the DC. However, the DC has never had
192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.

I've even fired up regedit on the DC to search for the IP address, and
all I'm showing is the one it's supposed to have - 192.168.61.31

I'm more than a little baffled by this one.

One thing I should note, just because: The DC in the AU office is a
machine that had been used in the US office about two years ago. We did
a P2V on it, and the VM from that still lives on in the US office.
They do share a MAC address (I don't know why, as I would have expected
the the MAC to change when it got the virtual NIC), but AFAICT this
shouldn't make a difference, since they are in different subnets
entirely, with different addresses.

Anyone have thoughts on this?

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin
Confidentiality Notice: 

--



This communication, including any attachments, may contain confidential 
information and is intended only for the individual or entity to whom it is 
addressed. Any review, dissemination, or copying of this communication by 
anyone other than the intended recipient is strictly prohibited. If you are not 
the intended recipient, please contact the sender by reply email, delete and 
destroy all copies of the original message.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

RE: A real puzzler...

2010-10-30 Thread Blackman, Woody

If the error is on the VM Guest, it could be a ghosted NIC from the P2V

To work around this behavior and display phantom devices when you use the Show 
hidden devices command: 

Click Start, click Run, type cmd.exe, and then press ENTER.
Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
Type Start DEVMGMT.MSC, and then press ENTER.
Click View, and then click Show Hidden Devices.
Expand the Network Adapters tree.
Right-click the dimmed network adapter, and then click Uninstall.

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Friday, October 29, 2010 10:49 PM
To: NT System Admin Issues
Subject: A real puzzler...

All,

I'm in the US, and have a problem in our AU office that I'm having difficulty 
wrapping my brain around. I have a theory, but it is still a strange situation, 
and any feedback anyone can provide would be appreciated.

The AU office has a server, which I've just recently stood up, using an address 
assigned by DHCP. This is not ideal, obviously, but the thing refuses to take 
the static IP address that it's slated to get
(192.168.61.30.) It's a VM on a new ESXi server.

When I try to assign it the static address, it keeps getting an error message 
that another machine has the address.

However, when I ping the IP address that the machine refuses to use, I get no 
answer.

When I use netmon on the VM in the AU office to capture ARP traffic, I get a 
MAC address that's for the DC. However, the DC has never had
192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.

I've even fired up regedit on the DC to search for the IP address, and all I'm 
showing is the one it's supposed to have - 192.168.61.31

I'm more than a little baffled by this one.

One thing I should note, just because: The DC in the AU office is a machine 
that had been used in the US office about two years ago. We did a P2V on it, 
and the VM from that still lives on in the US office.
They do share a MAC address (I don't know why, as I would have expected the the 
MAC to change when it got the virtual NIC), but AFAICT this shouldn't make a 
difference, since they are in different subnets entirely, with different 
addresses.

Anyone have thoughts on this?

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

2010-10-29 Thread Ben Scott

On Sat, Oct 30, 2010 at 1:49 AM, Kurt Buff  wrote:
> I'm more than a little baffled by this one.

  It does sound weird.  Random thoughts follow, no particular order,
sleep-deprived brain, so use at your own risk.  :)

> However, when I ping the IP address that the machine refuses to use, I
> get no answer.

  Maybe try nmap with a full port scan, see if anything else comes back?

> When I use netmon on the VM in the AU office to capture ARP traffic, I
> get a MAC address that's for the DC.

  Do you see anything else for that IP address besides an ARP "is-at" message?

> I've even fired up regedit on the DC to search for the IP address, and
> all I'm showing is the one it's supposed to have - 192.168.61.31

  There are other ways to store IP addresses (e.g., binary data, or
outside the registry entirely), so that's not entirely conclusive.

  On the DC, check RRAS (Routing and Remote Access), see if .30 is
configured for dial-in or something like that.

  Check the following on the DC for clues:

getmac
ipconfig /all
netsh -c interface show interface
netsh -c interface show alias

  Can you temporarily shut down the misbehaving DC (or disable its
switch port) and see if the ARP still comes back?  Long shot, but
maybe something's spoofing it.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

A real puzzler...

2010-10-29 Thread Kurt Buff

All,

I'm in the US, and have a problem in our AU office that I'm having
difficulty wrapping my brain around. I have a theory, but it is still
a strange situation, and any feedback anyone can provide would be
appreciated.

The AU office has a server, which I've just recently stood up, using
an address assigned by DHCP. This is not ideal, obviously, but the
thing refuses to take the static IP address that it's slated to get
(192.168.61.30.) It's a VM on a new ESXi server.

When I try to assign it the static address, it keeps getting an error
message that another machine has the address.

However, when I ping the IP address that the machine refuses to use, I
get no answer.

When I use netmon on the VM in the AU office to capture ARP traffic, I
get a MAC address that's for the DC. However, the DC has never had
192.168.61.30 - it's been 192.168.61.31 all its life in the AU office.

I've even fired up regedit on the DC to search for the IP address, and
all I'm showing is the one it's supposed to have - 192.168.61.31

I'm more than a little baffled by this one.

One thing I should note, just because: The DC in the AU office is a
machine that had been used in the US office about two years ago. We
did a P2V on it, and the VM from that still lives on in the US office.
They do share a MAC address (I don't know why, as I would have
expected the the MAC to change when it got the virtual NIC), but
AFAICT this shouldn't make a difference, since they are in different
subnets entirely, with different addresses.

Anyone have thoughts on this?

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

Re: A real puzzler...

RE: A real puzzler...

RE: A real puzzler...

RE: A real puzzler...

Re: A real puzzler...

A real puzzler...

31 matches

Site Navigation

Mail list logo

Footer information