No announcement yet.

Create large AD with High Availability for POS terminals and unreliable WAN links

  • Filter
  • Time
  • Show
Clear All
new posts

  • Create large AD with High Availability for POS terminals and unreliable WAN links

    I am having doubts on how to architect a complete new AD structure for the place I am working at.
    We have a large number of stores that currently are not part of any Domain.
    We plan to place a SQL server in each store as part of a new POS implementation and also migrate to XP Embedded for the POS terminals.

    Now the questions arises, how to tie all POS terminals, SQl servers into a new domain.
    Currently we do not have Domain at our corporate office so we like to create the following:

    - 1 Root forrest with 2 domains: Corp_domain and Store_domain.
    - Redunt Domain controllers at Corp. office
    - in each of the 5 cities that we have stores in: Add domain controller role to the SQL Server in the main store. This will function as the nearest domain controller for the stores in that city.

    - 40 stores in 5 cities
    - About 20 POS terminals per store
    - 400 Corporate users
    - Windows 2003 R2 servers, SQL 2005, XP embedded
    - 384K Wan Links, E1 link to each Regional Office. Each week we have several outages that can last from minutes to several hours

    - What will happen to the login times on the POS terminal when a store wan links goes down? I can not have the POS terminal down for a few minutes in case it need to reboot during such a situation.
    - Will the POS terminal in the store be able to connect to that stores SQL server will the Wan link to the store is down?

    - Would it be safer to add the domain controllers role to all store SQL servers?
    - How much administrative overhead will such a setup create for the sysadmin?
    - How much traffic will this add the the wan links?

    I appreaciate anyone who can give me information on these questions or can point me to any improvements.

  • #2
    Re: Create large AD with High Availability for POS terminals and unreliable WAN links

    I have some experience with similar projects, but first I need some more information:

    1. What kind of POS application are you using? Is it installed locally? is it web-based? does it have built-in authentication (meaning, do users log in within the application, or the application detects the currently logged on user)

    2. Does your POS workstations currently joind to domain? Is there a specific reason you want to join them to a domain?

    3. Do you have specific requirements in terms of Logon times from the management?

    4. Do you have, or do you consider purchasing any third party software for distribution of OS Images, software, patches, configuration updates?

    5. Are you plan on using domain users on your POS workstation login, or you plan on using local users?


    • #3
      Re: Create large AD with High Availability for POS terminals and unreliable WAN links

      1- In house POS system installed local on each POS terminal with SQL 2005 Express installled. Connect to Store Sql 2005 backend for syncing with Corporate server. POS software still in requirements phase, but likely will boot up and connect to domain as Checkout##_Store##. Cashier username will be added local in the backoffice on a per-store basis. (Due to high rotation of checkers this is better done on a store level)

      2- Current POS is DOS based. We believe for security and enforcement of policies the new POS should be part of a Active Directory.

      3- POS are critical apps and is designed to be able to work in stand-alone mode without LAN, WAN etc. We are being told by a Partner that some credentials are cached local in the POS terminal, and could consider doing a simple local login to the Stores SQl Server, in case of WAN failure.

      4- We are design the XPE footprint to be around 300MB Max and store Images local on the SQL server. In case of version update to the Image, the Terminal will pull this in over the LAN.

      5- We do not yet have SOX or PCI like requirements so in order to reduce corporate workload / delays etc we deal with local users being added local in the store. The POS terminal will login the domain to allow access to resources like the Creditcard gateway, OS updates, Antivirus etc.


      • #4
        Re: Create large AD with High Availability for POS terminals and unreliable WAN links

        Windows XPE caches credentials and will allow a user that previously logged on the machine to log on again even if fails to contact the DC.

        You can also test WinFLP which has a smaller foot print and provides better performance than XPE.

        Distributing Domain Controllers to each store would increase the TCO of your IT and the complexity of you AD infrastructure. Especially on unreliable communication links.

        In my opinion, you should test startup and logon times for domain accounts in the branches without a local DC and see if it's fast enough.

        You should tend, as much as possible, to minimize the use of Group Policy, Logon and Startup scripts to maintain fast logons. I don't think 384Kb communication link will be sufficient for 20 POS workstations to logon simultaniously.

        In order for this to work properly even when communication with the main site is down, you should use some kind of replication mechanism from the main site to stores' servers. You can use a simple Batch file, or you can use some 3'Rd party product. If you have Windows 2003 R2 or higher OS, you can use DFSR which is pretty stable. Do not use DFS for this.

        Use this mechanism to replicate scripts, reg files and any other file that should be retrieved by client machines at startup or logon and configure client machines to retrieve these files from the local store server and not from the main site.

        Doing so, machines will not be dependent on the link to the main site.

        I'm not familiar with the Creditcard gateway you are using. I assume it works through the local store server since it is critical.

        Regarding Anti Virus, you should distribute the signature files and updates to the local store server and have client machines retrieve it during non-working hours.

        Regarding OS patches, I believe you should consider purchasing a 3'Rd party product which you can use to first distribute patches to one or two machine, and after you're sure it does not harm the system, distribute it to all machines during non-working hours. (Same thing with AV).

        There are hundreds of products out there for distribution of patches and configuration. Take a look at bigfix. Every customer of mine which has it is satisfied.

        If your budget allows, I strongly suggest considering investment on good and reliable communication links before the project starts. At my experience, once the upper management get used to receive information from stores at real-time (or nearly real-time), they will be very annoyed if it is taken from them (even for a short period of time even for small number of stores) because of broken communication links.

        Another thing you should test thoroughly is the recovery of the replication between the local store's SQL to the large SQL in the main site when a communication link was broken and then restored.
        In this scenario, you should make sure that the replication process overcomes these situations and does not get out of sync.


        • #5
          Re: Create large AD with High Availability for POS terminals and unreliable WAN links

          Those a great point to take to the meeting.

          You're right the SQL replication is a big issue as management wants up to data at their finger tips.

          At this point have not yet started with the details of this, but I assume we will do a full sales and inventory replication each night and a hourly sales replication. We are a 24/7 operation but nights are mostly used for stocking etc.

          So far it sounds to me that this can be a good solution:

          1 Regional DCs. These are on E1 links and can have a secured server.
          2 NO RWDC or RODC in the stores
          2a Have logon related data cached on Store server to speed up logon process and avoiding WAN usages.
          3 POS Terminal logs in domain for administrative purposes (Antivirus, Patches, etc) but is not required to function as POS Terminal
          4 POS terminal has SQL 2005 express with all POS data local for HA purposes, and syncs this on each reboot or when pushed from the Store Server.
          5 If POS terminal cannot reach DC, it logs in locally (Can this be done automatically?) and uses local account to start POS Application.
          6 POS application contains the logic to connect to the Store SQL server.
          7 POS application contains the logic to have Application users login with their credentials. These are stored per store level only.
          8 POS application will contain logic to connect over WAN or Backup Modem to payment gateway.
          9 From corporate we control in a separate domain the store resources: Back office personal, POS terminals, Servers, Printers, Kiosks etc. (No POS user accounts. This could be done thru the POS application back office)

          Question: What is the sequence for a POS terminal when it boots and it cannot log in to the domain?
          - Will it detect this fast and continue on local mode? (Needed)
          - Will it ask for user input? (Not wanted)


          • #6
            Re: Create large AD with High Availability for POS terminals and unreliable WAN links

            Logon process when the DC is not available should not cause a noticable delay. If you have a laptop which is a domain member, it is the same operation that happens when you boot it up and log on when you're at home.
            So, when the DC is down, you can still use the domain account (and not local accounts) to logon.
            That would be the prefered way.

            You can bypass any user input (including windows logon screen).
            If you'r authentication is taking place within the POS software, then you can configure each POS machine for autologon using its dedicated domain (or local) user account and you can also replace the shell to the POS application so Windows Explorer would not even be loaded. That will also make the entire boot process faster.

            However, in order to replace the shell you will still have to do a little trick so when the user closes the POS application the POS terminal will either reboot or restart the POS application.