The XtremIO side of this is fairly trivial, and you'll find examples of doing it in the PowerShell guide.
The problem is that there's a LOT more to this process than just the array side. The real work is at the database level, as well as at the OS level, and if you're verbalized, the hyper-visor level which adds a serious amount of complexity.
I would suggest searching on the Internet to see if others are doing this with non-XtremIO platforms - most likely you'll be able to use the vast majority of what they are doing, and just replace one or two commands that actually do the array-level refresh which should be the only part that's really array-specific.
Why is AppSync not an option? This is exactly what it's designed to do - specifically the coordination between the database, OS, hypervisor and the array. If the issue is that you want it to be automated rather than using the GUI, AppSync has a REST API and a CLI, so it can be driven as a part of the PowerShell/etc script.
AppSync also includes a lot of functionality that people overlook when attempting to script things like this themselves - such as what happens if you add an additional LUN/drive to the database. Unless you've scripted a lot of intelligence into your script, the next time you do a refresh it's going to break as it'll be missing that new drive. However AppSync will automatically detect the addition of the new drive, and include it in what needs to be snapshotted/presented to the host/etc.
Appsync is not an option in our shop as it has been more of a PITA than it's worth. We have had nothing but problems with Appsync and VSS on the Windows hosts. To be fair, a lot of our problems are due to long running SQL jobs that are still running during the time that we were allotted for Appsync to run, on the source and target hosts. In order to complete the snap process and provide our clients with a usable copy we have decided to remove Appsync from the mix and just do the snap on the array without touching the source DB. And, since our clients have given us this particular time slot to complete the job, even though they constantly trespass in it with their jobs, we are going to use the bulldozer approach and just get it done, even if that requires a reboot of the mount host. We are also trying to create a "generic" script that can be ran against other vendor arrays in the future as there is a pending migration away from the XIO platform.
You may want to have a look at the latest version of AppSync.
I'm not a Windows/SQL guy so I don't pretend to know the full details, but I believe they have added the ability to skip VSS and take what is basically a crash consistent copy of the database, which might overcome at least some of your problems.
Also keep in mind that you can run custom scripts at various points during the process, which might help especially on the target side (eg, killing all running connections to that database, if that's something you wanted to do...)
When we first installed our XIO frames Appsync was not available and Replication Manager did not work with XIO, so our AIX team jumped in and wrote scripts using CLI (not restful). The Windows team prefered to wait for Appsync.
Once Appsync was available, we trudged through it's growing pains and had many conversations with support/development regarding stuff that didn't work, stuff that was incorrectly working, and stuff that wasn't in the product.
Assuming the budget is approved we will be moving towards a different vendor's flash array, for a myriad of reasons, so we ultimately will not be using Appsync. That's why we're trying to redesign this snap process with the simplest methods and tools that we have the most experience with.
Initially we decided to write everything on the Windows box using Powershell. That is not going well as we don't have a lot of experience designing and wrapping all of these commands together. We are now starting a parallel task to do this from a unix VM as well.
IMHO this will probably ultimately end up being done on the unix box with a few ssh calls to the Windows box to stop the db and unmount the volumes, then a CLI on the unix box to the XMS to snap-reassign the volumes, then another ssh to the Windows host to mount and start the DB. It might sound convoluted but it's just the raw version of what's being done already. And that's only because I'm a recovering *nix Sysadmin.
On unix I can easily issue the CLI to do all these commands. On Windows we need to figure out JSON, figure out Powershell, then figure out how to make them work nice together. That's a few too many steps and time to put into product that we are moving away from.