script to disjoing/rejoin domain

I have saved the system log. I just had another machine fall off the domain
again and had to rejoin it to the domain.

Is there anyway I can get some help diagnosing this? This is becoming a
serious issue
"joey" <joe@abc.com> wrote in message
news:ukj4vXdyJHA.4164@TK2MSFTNGP03.phx.gbl...
> yes it is using the physical host nic but has a separate ip address
> "Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
> news:ff16fb66212e78cb966ef24dd401@msnews.microsoft.com...
>> Hello Ace Fekay [Microsoft Certified Trainer],
>>
>> I think with "natted" he means the VM's ip address uses the physical host
>> NIC.
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>
>>> "Joey" <joey@joey.com> wrote in message
>>> news:%23$oT$DCyJHA.4272@TK2MSFTNGP06.phx.gbl...
>>>
>>>> these are virtual machines "natted" through the host pc to get to the
>>>> domain. But they are just falling off. I have no idea why
>>>>
>>> Domain communication traffic through a NAT is not supported, unless
>>> VPN is used between the NAT subnet and the main or outside (not
>>> internet) subnet. Thsi is because NAT does not support Kerberos, RPC
>>> or LDAP traffice.
>>>
>>> The information you've provided in your thread is not enough to
>>> diagnose this issue. This is similar to visiting a doctor. You say it
>>> hurts. What hurts? We need blood work, blood pressure readings, etc
>>> (you catch the drift). In order to properly diagnose the issue, we do
>>> actually need configuration information, and the info that I
>>> previously asked for is paramount in a diagnosis or at least a good
>>> start. The info about the NAT setup is not a good sign, because of
>>> it's limited ability to traverse domain traffic, but there may be
>>> something I am not seeing, because of the limited info you've
>>> provided.
>>>
>>> Can you describe this setup in more detail, including a logical
>>> (non-image) diagram including subnet IP ranges, what DNS address they
>>> are using, etc? Additional info:
>>>
>>> Unedited ipconfig /all from a DC, from a working client and from the
>>> virtual client. Event log errors, if any, from the DC, a working
>>> client and from the virtual client.
>>>
>>> If you can't supply this information due to security or other reasons,
>>> I can understand. If this is the case, remove the NAT between the VMs
>>> and the main subnet, route them directly through, or make them part of
>>> the same subnet, and report back if it still occurs.
>>>
>>> And as Meinolf mentioned, I also have customers with machines joined
>>> to their domain for a number of years, and this has never happened to
>>> me nor have I ever seen this issue before. That is why we believe it
>>> is a infrastructure DNS design/resolution issue, or something simple,
>>> such as trying to communicate through a NAT. The NAT seems to be a
>>> major reason sticking out right now.
>>>
>>> Ace
>>>
>>
>>
>
>

 

on the DC I can find this in the sec log

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 5/4/2009
Time: 9:32:23 AM
User: NT AUTHORITY\SYSTEM
Computer: DC3
Description:
Pre-authentication failed:
User Name: machine$
User ID: domain\machine$
Service Name: krbtgt/domain.com
Pre-Authentication Type: 0x2
Failure Code: 0x18
Client Address: 10.x.x.x

any idea?




For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

"joey" <joe@abc.com> wrote in message
news:ukj4vXdyJHA.4164@TK2MSFTNGP03.phx.gbl...
> yes it is using the physical host nic but has a separate ip address
> "Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
> news:ff16fb66212e78cb966ef24dd401@msnews.microsoft.com...
>> Hello Ace Fekay [Microsoft Certified Trainer],
>>
>> I think with "natted" he means the VM's ip address uses the physical host
>> NIC.
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>
>>> "Joey" <joey@joey.com> wrote in message
>>> news:%23$oT$DCyJHA.4272@TK2MSFTNGP06.phx.gbl...
>>>
>>>> these are virtual machines "natted" through the host pc to get to the
>>>> domain. But they are just falling off. I have no idea why
>>>>
>>> Domain communication traffic through a NAT is not supported, unless
>>> VPN is used between the NAT subnet and the main or outside (not
>>> internet) subnet. Thsi is because NAT does not support Kerberos, RPC
>>> or LDAP traffice.
>>>
>>> The information you've provided in your thread is not enough to
>>> diagnose this issue. This is similar to visiting a doctor. You say it
>>> hurts. What hurts? We need blood work, blood pressure readings, etc
>>> (you catch the drift). In order to properly diagnose the issue, we do
>>> actually need configuration information, and the info that I
>>> previously asked for is paramount in a diagnosis or at least a good
>>> start. The info about the NAT setup is not a good sign, because of
>>> it's limited ability to traverse domain traffic, but there may be
>>> something I am not seeing, because of the limited info you've
>>> provided.
>>>
>>> Can you describe this setup in more detail, including a logical
>>> (non-image) diagram including subnet IP ranges, what DNS address they
>>> are using, etc? Additional info:
>>>
>>> Unedited ipconfig /all from a DC, from a working client and from the
>>> virtual client. Event log errors, if any, from the DC, a working
>>> client and from the virtual client.
>>>
>>> If you can't supply this information due to security or other reasons,
>>> I can understand. If this is the case, remove the NAT between the VMs
>>> and the main subnet, route them directly through, or make them part of
>>> the same subnet, and report back if it still occurs.
>>>
>>> And as Meinolf mentioned, I also have customers with machines joined
>>> to their domain for a number of years, and this has never happened to
>>> me nor have I ever seen this issue before. That is why we believe it
>>> is a infrastructure DNS design/resolution issue, or something simple,
>>> such as trying to communicate through a NAT. The NAT seems to be a
>>> major reason sticking out right now.
>>>
>>> Ace
>>>
>>
>>
>
>

 

what do you mean its not supported? It find the DC ok and joins the domain.
Users can open outlook etc connect to exchange etc...

The difference is these are virtual machines on a natted network.

say for example, the host ip is 10.10.10.5

The virtual machine runnon on this host is natted through 10.10.10.5 and
using something like a

192.168.0.5


"Ace Fekay [Microsoft Certified Trainer]" <aceman@mvps.RemoveThisPart.org>
wrote in message news:uS9FFaEyJHA.4116@TK2MSFTNGP04.phx.gbl...
"Joey" <joey@joey.com> wrote in message
news:%23$oT$DCyJHA.4272@TK2MSFTNGP06.phx.gbl...
> these are virtual machines "natted" through the host pc to get to the
> domain. But they are just falling off. I have no idea why


Domain communication traffic through a NAT is not supported, unless VPN is
used between the NAT subnet and the main or outside (not internet) subnet.
Thsi is because NAT does not support Kerberos, RPC or LDAP traffice.

The information you've provided in your thread is not enough to diagnose
this issue. This is similar to visiting a doctor. You say it hurts. What
hurts? We need blood work, blood pressure readings, etc (you catch the
drift). In order to properly diagnose the issue, we do actually need
configuration information, and the info that I previously asked for is
paramount in a diagnosis or at least a good start. The info about the NAT
setup is not a good sign, because of it's limited ability to traverse domain
traffic, but there may be something I am not seeing, because of the limited
info you've provided.

Can you describe this setup in more detail, including a logical (non-image)
diagram including subnet IP ranges, what DNS address they are using, etc?
Additional info:

Unedited ipconfig /all from a DC, from a working client and from the virtual
client.
Event log errors, if any, from the DC, a working client and from the virtual
client.

If you can't supply this information due to security or other reasons, I can
understand. If this is the case, remove the NAT between the VMs and the main
subnet, route them directly through, or make them part of the same subnet,
and report back if it still occurs.

And as Meinolf mentioned, I also have customers with machines joined to
their domain for a number of years, and this has never happened to me nor
have I ever seen this issue before. That is why we believe it is a
infrastructure DNS design/resolution issue, or something simple, such as
trying to communicate through a NAT. The NAT seems to be a major reason
sticking out right now.

Ace

 

"Joey" <joey@joey.com> wrote in message
news:uYd8ahOzJHA.2656@TK2MSFTNGP05.phx.gbl...
> what do you mean its not supported? It find the DC ok and joins the
> domain. Users can open outlook etc connect to exchange etc...
>
> The difference is these are virtual machines on a natted network.
>
> say for example, the host ip is 10.10.10.5
>
> The virtual machine runnon on this host is natted through 10.10.10.5 and
> using something like a
>
> 192.168.0.5
>
>
> "Ace Fekay [Microsoft Certified Trainer]" <aceman@mvps.RemoveThisPart.org>
> wrote in message news:uS9FFaEyJHA.4116@TK2MSFTNGP04.phx.gbl...
> "Joey" <joey@joey.com> wrote in message
> news:%23$oT$DCyJHA.4272@TK2MSFTNGP06.phx.gbl...
>> these are virtual machines "natted" through the host pc to get to the
>> domain. But they are just falling off. I have no idea why
>
>
> Domain communication traffic through a NAT is not supported, unless VPN is
> used between the NAT subnet and the main or outside (not internet) subnet.
> Thsi is because NAT does not support Kerberos, RPC or LDAP traffice.
>
> The information you've provided in your thread is not enough to diagnose
> this issue. This is similar to visiting a doctor. You say it hurts. What
> hurts? We need blood work, blood pressure readings, etc (you catch the
> drift). In order to properly diagnose the issue, we do actually need
> configuration information, and the info that I previously asked for is
> paramount in a diagnosis or at least a good start. The info about the NAT
> setup is not a good sign, because of it's limited ability to traverse
> domain traffic, but there may be something I am not seeing, because of the
> limited info you've provided.
>
> Can you describe this setup in more detail, including a logical
> (non-image) diagram including subnet IP ranges, what DNS address they are
> using, etc? Additional info:
>
> Unedited ipconfig /all from a DC, from a working client and from the
> virtual client.
> Event log errors, if any, from the DC, a working client and from the
> virtual client.
>
> If you can't supply this information due to security or other reasons, I
> can understand. If this is the case, remove the NAT between the VMs and
> the main subnet, route them directly through, or make them part of the
> same subnet, and report back if it still occurs.
>
> And as Meinolf mentioned, I also have customers with machines joined to
> their domain for a number of years, and this has never happened to me nor
> have I ever seen this issue before. That is why we believe it is a
> infrastructure DNS design/resolution issue, or something simple, such as
> trying to communicate through a NAT. The NAT seems to be a major reason
> sticking out right now.
>
> Ace
>
>
>
>

NAT can't traverse some of the required protocols that domain communications
require. This is because of the way NAT works. It translates the source to a
different internal IP, but at the same time it tries to translate the
packet, but it can't due to the security on the packet, such as using RCP.
With NAT designs, it is usually setup with hardware devices that you can use
a VPN tunnel between locations.

If you set it up with an IP on the subnet instead of NAT, I believe your
problems may go away.

Also there were a couple of requests for configuration information. I
haven't seen any responses in this area. So most of this stuff is conjecture
anyway on our part based on the limited information you've provided.

Ace