Auxilary Clinet - How it works when domain fails ?
Below poin is mentioned in Auxiliary client release document:
Only users who are previously logged in, can log in to an auxiliary workplace node when the main system is down. This is under the assumption that connection to the domain controller(s) is impacted by the failure. If not, then log in can happen as usual, i.e. also by persons who have not been previously logged in.
If this is the case Normal 800xa system also should be not effected if both domain fails ?
When we have shutdown both domain operator workplace which was logged in with operator user name stopped working ?
Only users who are previously logged in, can log in to an auxiliary workplace node when the main system is down. This is under the assumption that connection to the domain controller(s) is impacted by the failure. If not, then log in can happen as usual, i.e. also by persons who have not been previously logged in.
If this is the case Normal 800xa system also should be not effected if both domain fails ?
When we have shutdown both domain operator workplace which was logged in with operator user name stopped working ?
Answers
System 800xA can be used either in a Microsoft Windows Workgroup or a Microsoft Windows Domain.
If you select domain, the system need to have a domain controller reachable at all times (among other things, to be able to fulfil requirements of proper authentication before allowing a write operation). If a user is e.g. disabled in Microsoft Active Directory or a permission is changed thru System 800xA Point Of Control, etc. it must be effectuated/validated immediately.
It is true that you may be able to login to a domain member computer even if all domain servers are down using a cached credential; however cached credentials does not count when the system need to authenticate a user before he or she performs a privileged interaction in the system.
Do not run any System 800xA node (in a system using domain configuration) without a domain controller in reach.
An auxiliary client is just another name for "aspect server". Like all other servers, auxiliary clients deserves a potent hardware and good network connection.
Recall that the write performance of System 800xA is set by the slowest acting aspect server (all aspect servers incl. auxiliary clients need to accept a transaction before it will be committed). Having one or two "aspect servers" running on less powerful hardware and/or on distant (=slow) network connection is not recommended. More servers = more overhead. Note that the total number of aspect servers (including auxiliary clients) must be 1, 2 or any higher odd number.
If you select domain, the system need to have a domain controller reachable at all times (among other things, to be able to fulfil requirements of proper authentication before allowing a write operation). If a user is e.g. disabled in Microsoft Active Directory or a permission is changed thru System 800xA Point Of Control, etc. it must be effectuated/validated immediately.
It is true that you may be able to login to a domain member computer even if all domain servers are down using a cached credential; however cached credentials does not count when the system need to authenticate a user before he or she performs a privileged interaction in the system.
Do not run any System 800xA node (in a system using domain configuration) without a domain controller in reach.
An auxiliary client is just another name for "aspect server". Like all other servers, auxiliary clients deserves a potent hardware and good network connection.
Recall that the write performance of System 800xA is set by the slowest acting aspect server (all aspect servers incl. auxiliary clients need to accept a transaction before it will be committed). Having one or two "aspect servers" running on less powerful hardware and/or on distant (=slow) network connection is not recommended. More servers = more overhead. Note that the total number of aspect servers (including auxiliary clients) must be 1, 2 or any higher odd number.
Add new comment