6 Replies Latest reply on Jul 18, 2017 2:26 AM by synicalx

    Migrating on-prem EPO to Azure


      Hey all,


      My organisation is looking to move an on-prem installation of EPO up into Azure, we have an express route connection to Azure a ton of credits so we're essentially looking to make the most of this while we're decommissioning most/all of our on-prem kit.


      Scenario is; we have a herd of roughly 300 workstations on site that are currently being looked after by our singular EPO VM. We are basically looking to lift and shift this into Azure as-is and dump it on another VM. My other thought was to drop the SQL side of it into an SQL-as-a-service instance in Azure. In either case I intend of having a Super Agent remain behind on-prem to act as a repository for updates etc.


      Now what I'm trying to work out is if this is a sane/sensible plan, and more importantly if this has been done before?


      Any input would be greatly appreciated, thanks!

        • 1. Re: Migrating on-prem EPO to Azure
          Richard Carpenter

          Hi synicalx


          Great idea, I had never thought of doing that.


          A few questions if I could to help answer your query.


          Your existing EPO VM - which hypervisor are you using, VMWare, HyperV? - If you are using HyperV it should be a simple exercise to 'push' the vhd to Azure.

          Current SQL DB? It is running on an 'external' SQL Server or, as I assume, are you running SQL Express?


          The SQL Database will need to go up to Azure either as Paas (AzureDB) or IaaS included as SQLExpress in your VM. The Application server (EPO) need a low latency connect to the SQL database and running the Database on premiss - although via Express Route would probably be too slow and may introduce some security issues.


          This may well be informed from a cost point of view, but if were going to do this I would probably lift and shift the existing vhd/vdmx file first and if you wanted to divorce the DB from the VM do that later.


          Depending on your Express Route network ACLs and the risk appetite of the business a Super Agent would most likely be the best architecture route with either Lazy caching or even a distributed repository.


          Sounds like a great project, best of luck.


          Richard Carpenter, CISSP

          McAfee Volunteer Moderator - Business

          McAfee Certified Product Specialist - ePO

          • 2. Re: Migrating on-prem EPO to Azure

            Hey Richard,


            Thanks for your reply, great to hear a second opinion here.


            We're on ESX at the moment, so the migration from that to Azure won't be as straight forward as Hyper-V unfortunately. The on-prem installation is in a really awkward position - it lives on the same VM that houses an SQL server, and SCCM. So at the moment it's using the full version of SQL but doesn't necessarily need to be, Express edition will work fine for our needs.


            I think for the moment, I might lab this up in Azure and see how it goes. Hopefully I can post back with updates here for future reference



            • 3. Re: Migrating on-prem EPO to Azure

              Hi synicalx


              We're currently considering migrating our McAfee EPO server into Azure and looking into utilising Azure SQL PaaS as the backend DB configuration,


              As this is something similar to what you attempted back in 2016 would you be kind enough to provide us with the outcome of your findings?


              If successful I wonder if McAfee would still provide a support function should we ever encounter future issues.


              Thanks in advance,


              • 4. Re: Migrating on-prem EPO to Azure

                Hi stekin,


                We migrated with no real issues, but we did end up using a standalone SQL server (Azure VM) to run the DB. In testing though the PaaS SQL seemed fine though.


                The only problem we encountered was network related - tasks and deployments tended to fail or time out a bit more than usual, but when we increased the number of attempts on each one they worked normally.


                On the support, I've logged a couple of support cases and there's been no issues, but I've not been asked by the support engineers what platform we're running the server on.




                • 5. Re: Migrating on-prem EPO to Azure

                  Thanks Zac, appreciate the feedback synicalx,


                  So what was the main reason to chose a standalone SQL VM over the PaaS service?


                  Thanks Again,


                  • 6. Re: Migrating on-prem EPO to Azure

                    Hi stekin


                    No problem!


                    For us it was just a policy thing, we're a government agency and we have certain requirements for products we use. Unfortunately, a lot of the SaaS and PaaS solutions from various vendors (MS included) don't meet all of these requirements so we're stuck with running our EPO DB on an old-fashioned SQL server.