I have created 4 Active Directory Domain Controllers both in different locations. One is in Delhi and Another one in Mumbai.
Delhi has 2 domain controllers Primary(DDC01) and Secondary(DDC02).
Mumbai has 2 domain controllers Primary(MDC01) and Secondary(MDC02).
Both have different networks and I can take the RDP of both Domain controllers from different locations.
Now I want to connect all 4 Domain Controllers so they can replicate the data and policies.
I saw this can be done through Active Directory Site and Services.
I Added Subnet's of Both Sites in Mumbai DC i.e. MDC01
I created Sites such as Mumbai-HO and Delhi-BO in MDC01 it got replicated to MDC02.
I could see MDC01 and MDC02 but I cannot see any of the DDC01 or DDC02 showing there.
Am I missing something?
Just FYI... DDC01 and DDC02 are having different gateways due to some reason.
• Please check the active directory site replication ports are open between for communication between the Mumbai and Delhi sites by doing telnet from command prompt on each of the ports. The inbound as well as outbound communication from these to ports to each other sites should be successful. Please find the list of ports as below: -
UDP Port 88 for Kerberos authentication
UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
TCP and UDP Port 445 for File Replication Service
TCP and UDP Port 464 for Kerberos Password Change
TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.
• Check the replication status of the AD sites through the repadmin utility by running the below command on the replicating DCs in powershell: -
‘ repadmin /syncall /force ’ or ‘ repadmin /syncall /APeD ’ or ‘ repadmin /replsum ’
If the message replied in the powershell states that ‘Syncall terminated with no errors’, then everything is fine and you need not worry about the replication status between sites. Also, you can check the replication topology status in AD Sites and subnets where all the sites are listed whether created automatically or manually as below: -
This will give out the replication status and issues relating to AD site replication. For more detailed information on the replication issues, execute the below command and check for replication issues on site level. This will give out the site wise information in csv format: -
‘ repadmin /showrepl * /csv > showrepl.csv ’
• Also, please check whether Delhi site is automatically created by KCC or not, if not, then wait for at least 24 hours after the above steps revert successful status of replication. The check the ‘Cost’ parameter of replication link in the site details workspace by clicking on it. It defines the priority level of network connection sync level between the two sites. Please find the snapshot below to know the actual cost of your network connection and set it accordingly: -
For more information on AD site replication issues, please refer the link below: -
https://learn.microsoft.com/en-GB/troubleshoot/windows-server/identity/common-active-directory-replication-errors
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/diagnose-replication-failures
Related
We've a Windows Event Collector in DOMAIN1. DOMAIN1 and DOMAIN2 have a two-way transitive forest trust. Events from sources in D1 are forwarding fine to the WEC in D1.
D2 is setup to communicate to the same FQDN subscription manager over http/5985 (Server=http://server1.domain1.com:5985/wsman/SubscriptionManager/WEC,Refresh=60). Source initiated event collection. Port 5985 is open and listening from D2 machines through WEC in D1.
Machines in D2 are getting this in their Eventlog-ForwardingPlugin Operational logs
The forwarder is having a problem communicating with subscription manager at address http://wec1.domain1.com:5985/wsman/SubscriptionManager/WEC. Error code is 2150858909 and Error Message is <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150858909" Machine="server1.domain2.com"><f:Message>WinRM cannot process the request. The following error with errorcode 0xc0000413 occurred while using Kerberos authentication: An unknown security error occurred.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. </f:Message></f:WSManFault>.
[eventlog][1]
I don't know enough about kerberos to know if tickets from D2 can be used in D1 or somehow made to. Anyone got any ideas? I can't find much about this exact issue and WEF.
thanks
[1]: https://i.stack.imgur.com/VVF0Y.png
I've a GPO that won't work in Azure AD. I need to create multiple GPOs to map network drives. I've put the GPO right under the domain
I've mapped the drive, and targeted at a security group. Tried with an OU first, but that didn't work either.
So did I place the GPO wrong, or did I map the drive wrong? The client has a dynamic IP and it's DNS servers are the IP of the servers
When I run gpudate on the client, It seems that the server is unreachable:
Let me know if you need additional information
• Your procedure of mapping a network drive is correct but the error snapshot that you have posted regarding the reachability of the AD/DNS servers is a matter of concern due to which the group policies were not able to replicate and apply authoritatively from the AD or Group policy server. Thus, please check the connectivity of the DC/Group policy server from the client system as below: -
A) Check the SYSVOL replication is happening correctly or not. DFRS (Distributed File Replication Service) is used for SYSVOL replication, to confirm that run the below command and check its result
‘ dfsrmig.exe /getglobalstate ’ --> If the result shows: 3 (ELIMINATED), then its Ok
B) Then check whether which DC has the FSMO roles installed on it. For that, run the below command and check the IP and hostname whether it is configured as the correct DNS in IP configuration in the client system or not
‘ netdom query fsmo ’
C) Once the above is done, please check the replication between the DCs is working correctly or not by executing the below commands one by one and analyzing their results
‘ Dcdiag /v >c:\dcdiag1.log
Repadmin /showrepl
Repadmin /syncall /APeD ‘
D) Ensure that the ‘gpt.ini’ file exists on your DC at ‘\domain.local\SysVol\domain.local\Policies{Policy_GUID}\’ path and if not then your GPO server might be at risk of corruption of essential system files. Please reset it. Also, do ensure that your DNS server or DC is reachable and pingable through the below commands successfully. Try to reset the DNS resolver cache on client computers.
‘ ping<hostname of DC>
Nslookup<hostname of DC>
Ipconfig /flushdns ’ on client systems
Lastly, ensure that your DC and domain is accessible via RPC protocol through the below command: -
‘ nltest /dsgetdc:hostname of DC ’
If all of the above commands return positive results, then you should check your client’s network and domain settings for any issues as everything else is correct on the DC end.
I am having issues with creating a failover cluster with an availabilty group.
I've made a windows failover cluster, and a sql availability group. I also have an azure load balancer with an IP address and a DNS name.
I am trying to follow this guide here
I get to the Configure the Listener, add Client access point, and things fail from there.
Is the name here supposed to be the DNS name in the load balancer? Same for the IP? Or is it supposed to be another object in Active directory.
Steps 5 and 6 seem to conflict, Is the dependency supposed to be a resource or an IP?
If anyone have any advice, I would be appreciative.
I have been using the above guide trying to get things to work in GUI before changing this over to powershell code.
I suspect either there is something I am missing, or this is all the same IP address and dns name used.
In one company there is windows server 2008 hosting firebird 2 database.
Clients are using some software to connect from local machines to this database.
Network is running on few mikrotik routers.
When i change main gateway mikrotik router dns to cleanbrowsing ip addresses (185.228.168.10 and 185.228.169.11), software can not connect fo this firebird database.
When i use 8.8.8.8 dns or 1.1.1.1 - no such problems.
Software does not relate to dns, i know this because it is written by me in c#.
How possible is that and why it happens?
Changing the main gateway router's DNS server to another upstream server means you are potentially getting different responses to DNS queries. Assuming that nothing else has changed on your network, I imagine one of the following:
Your new DNS provider does not have special config for the dns entries you are querying
Your new DNS provider is located somewhere else physically, and you are running into a situation where geolocation matters (different dns responses to differently located users)
There is another gadget on the network intercepting DNS and is unaware of the change you are making. For example a NAT rule on a router that redirects 8.8.8.8 to an internal DNS server.
I agree with your assessment that the software is probably not causing this, because you changed infrastructure, I think that this is an infrastructure problem.
With 15+ years of experience running FirebirdSQL in small networks, I always set following things to prevent such problems:
The first DNS at the router's DHCP should point to the router's IP (gateway) itself, so it resolves local pc names easier
Setting a (random?) DHCP domain name at router's setup is recommended too
Edit/replace the firebird.conf file with one of fixed default port (3050) + event port (3051).
Opening those ports on each PC's firewall is a MUST. Both incoming and outgoing. You may narrow it to local IP range to prevent outside attacks. (Create a script once, run it on each PC as Admin once.)
Usually I also add "fbserver.exe" to firewall exception too
Restart FirebirdSQL service (or the whole PC) after changing gateway or DNS or firebird.conf
I have hosted my WebApp on server 1 and my database on server 2
But I'm getting following error
Communication with the underlying transaction manager has failed.
I googled and found a post which mentioned that it is the issue of DTC(Distributed Transaction)
I enabled DTC on server2(DB server) and made an exception of it in Firewall.
But still same error.
Here is the full stack trace
Message: System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
Kindly advice
We had the exact same situation, and more than once. Each time, it was one of the following:
The IP address in the DNS for the server is outdated (as said in error message: "two machines cannot find each other by their NetBIOS names"). You can check if this is the case by trying ping servername from one server to another in the command prompt. If the ping by name fails and ping by IP succeeds (or ping by name returns the wrong IP), than you should talk to the System Admins to take a look at DNS/DHCP.
The servers are created as an image of preconfigured server (for example, if you are working with virtual machines, and instead of doing a fresh install for each of the servers, you simply clone the image). This is a problem because DTC has an internal "Identifier" - and in case of image cloning both your installations now have same DTC ID, and won't be able to communicate with each other. The solution is to simply uninstall and install the DTC again.
Hope it helps.
Things to check:
Have you done this configuration on both servers?
Are both servers members of the same domain?
Have you checked the event log?
I had the same problem while connecting to a remote SQl Server.
The solution in my case was to add "enlist=false" to the connection string.
I was missing quite a lot of things:
No authentication (as DB server and APP server and not within same AD domain)
Rule to Windows Firewall enabling msdtc.exe
Rule to firewall between DMZ and internal zone TCP 135,1024-65535 in both directions. The link tell you how to restrict the firewall policy to few ports only.
short / long server names to hosts or a shared DNS server. Eg. 192.168.1.1 app1 as well as 192.168.1.1 app1.domain.local
On the other hand based on this link my setup doesn't require:
Allow Remote Clients
Allow Remote Administration
Enable XA Transactions (required prior Windows Server 2003 SP1)
Solved after adding remote IP\machine name to files on server:
hosts, lmhosts
in folder
C:\Windows\System32\drivers\etc
One of our servers displayed this error after the Virtual Machine (VM) controlling our Domain Controller froze. Several related communication problems also started to pop up (like failed password resets). Resetting the frozen VM fixed the issue.
Lots of helpful answers already given.
One problem for me was the presence of invalid (cyrillic) characters in the computer name.
And there is also a way to validate the connection between two servers (or between a server and a computer) using a small tool from Microsoft called DTCPing.