New answers tagged

1

Are there any risks or caveats to take into account when adding an IPv4-only DC to an existing pool of DCs that are already configured with IPv4 and IPv6 enabled? - No. Also, don't disable the IPv6 components on the new DC. The fact that EC2 doesn't support IPv6 is irrelevant to the configuration and operation of the actual DC.


1

If your environment is healthy and properly redundant as you say, this is fine.


1

The way my Big 4 client does it is by creating rules in each client NSG that lets them talk to a specific management server (or servers) for monitoring, alerting, antivirus, updates, etc. Each NSG only allows communication for specific ip addresses for the specific ports required for each VM to talk to the "management" server. So there's no centralized ...


1

It sounds to me like you have configuration issues rather than it being an issue with AD. If the DC holding the FSMO roles (including PDC emulator Role) goes down then things will be a bit tough but if you have a second DC users should be able to authenticate, you should be able to create new users and features like GPOs should still process. Presuming ...


0

Regarding the second change issue... What is the domain policy setting for "minimum password age"? If that is a non zero number, you need to wait that time period before another change is allowed. You can find that info with powershell command Get-ADDefaultDomainPasswordPolicy or by looking in the Default Domain Policy at the path: Windows Settings/Security ...


1

The client's DNS configuration can be set as automatic, as long as the DHCP server (your router, I assume?) providing the configuration to the client gives the IP of the DNS server(s) associated with the Active Directory forest as the DNS server(s). Most often, the DNS IPs will be the domain controller(s). You will also want to set the default domain in the ...


1

AD is dependent upon and requires DNS. Windows AD clients need to locate Domain Controllers (among other things). They do this by querying a DNS server for the location (ip address) of a Domain Controller. In order for this to happen there must exist a DNS server or servers that host the DNS zone for the AD domain. This is most often (but not necessarily) a ...


1

The error you encounter is related to the fact that the context of the execution of the domain.shscript is different when you're logged in and when it is executed remotely by Ansible. See this SO question for more details. You need to complete the /root/startup_jboss.shscript with the missing environment variables in order to work correctly. You can test ...


2

A reason can be clock drift. If the workstation clock drifts more than 5 minutes away from the server's, it will lose connection to the Domain. This may come from flaky hardware, or when the system is powered off for quite a long time, or sometimes when a laptop is often away from the network, etc.


0

You can also check: Anti-Virus "End point security" which may hinder traffic to the IPC$ share (try removing this on a client machine you like to join) Ensure your DC is not multi-homed (e.g. make sure only one NIC, and one NIC only, is connected/active/live) HTH.


2

The 'why' is that in Microsoft Windows 2003 they extended their directory implementation to include forcing workstations to reset their passwords every 30 days or so. I know it well, it broke a lot of SAMBA installs I was maintaining at the time. Normally this password reset is all automatic, but I've seen many, many cases when this design just doesnt ...


2

The AD computer password process (documented here) hasn't changed much and is certainly not the root cause of broken schannel issues. (in fact it's the CLIENT that changes the password and the password is exempt from the password expiration policy. Now depending on the client OS is where things get interesting. 1 reason for lockout is XP. If it's XP and ...


2

The other way would be to use ADUC and reset the computer account (if it just got out of sync with the domain) simply right-click the computer name and choose "Reset Account" (about 80% of the time this will fix your issue).


7

Extending on Katherine's answer: A workstation will lose trust with the domain controller if its account has been overwritten. It is entirely possible (with the right permissions) to add a computer with a name that already exists in the domain, but this will cause the computer that was previously known as that name to lose trust with the Domain Controller.


29

You probably already know this, but bear with me. Computers have passwords in AD, just like users. We don't know our computer's password, and it changes regularly via built-in logic. The short answer is that the computer's password is no longer valid, and therefore AD doesn't trust this machine for logins any more. Why? How? Lots of things cause ...


0

If you're asking specifically about Hyper-V Replica then I think it might make sense to balance the load rather than have one host mostly idle. Set up a DC on each host, and then set up Exchange on one and SharePoint on the other. After this, set up your VM replication and you should be set. As already mentioned, you don't need to replicate your domain ...


3

Bring in some virtual shared storage and build a Hyper-V cluster. DCs have own replication built-in, and while you can fake HA with Hyper-V Replica for ordinary VMs it's not supported with Exchange and has issues with SharePoint. https://blogs.technet.microsoft.com/rmilne/2013/07/29/exchange-and-hyper-v-replica-support/



Top 50 recent answers are included