Comments
Sort by recent activity
Hi Ramūnas, Glad to hear it! I should make it clearer that these kinds of breaking changes are definitely out of the ordinary, and it's a policy of Clone's to retain backwards compatibility of our API within a major version. (In my previous post I made it sound as though such changes were an accepted fact of life.) In this case unfortunately something slipped through the cracks. We've since implemented a new suite of automated regression tests on our API to make this sort of thing less likely in the future. Owen / comments
Hi Ramūnas,Glad to hear it!I should make it clearer that these kinds of breaking changes are definitely out of the ordinary, and it's a policy of Clone's to retain backwards compatibility of our AP...
Hi Ramunas, Occasionally there are unavoidable changes to the Clone server API. As a result, anything expecting to target the old API falls over, including any old PowerShell cmdlets. You can re-download the cmdlets from the Clone UI's Settings page to upgrade them to the latest version. Sorry for the inconvenience - let me know if that doesn't solve the issue. (In future releases, we'll try to ensure the cmdlets give you a more sensible error message when you connect to a version of Clone that won't support them.) Many thanks, Owen / comments
Hi Ramunas,Occasionally there are unavoidable changes to the Clone server API. As a result, anything expecting to target the old API falls over, including any old PowerShell cmdlets. You can re-dow...
When masking an image, Clone will ignore the masking set's configuration for:
which database to mask (as Clone decides on the database's name when it attaches it for masking, so pre-defining the name won't work),
which instance and machine the database is on (as your masking set file may not know ahead of time which temporary instance will be used).
So if the masking set file expects to mask a database at MyMachine \ MyServer2014 \ MyDatabasebut in reality, for this run, Clone has attached the imaged database to SomeOtherMachine \ TemporaryInstance2016 \ SqlCloneTemp_yuR72then it's the latter that will be used, and the former details ignored. Hopefully that sheds some light on Clone's behaviour. / comments
When masking an image, Clone will ignore the masking set's configuration for:
which database to mask (as Clone decides on the database's name when it attaches it for masking, so pre-defining the na...
Hi Robert, We fixed an issue that sounds similar to what you're experiencing in Clone 4.4.33. Could you try updating the Clone server to that version (or newer), downloading and installing its PowerShell cmdlets from Settings, and retrying? Regarding your question, Clone server uses two ports - 14145 for communication with clients (that is, PowerShell cmdlets, and the web UI - it can also be configured to use a different port, and HTTPS) and 14146 for communication with agents. It won't vary by which cmdlet is called. Clients will always talk to the client port, and agents will always talk to the agent port, and they won't need to do otherwise.
/ comments
Hi Robert,We fixed an issue that sounds similar to what you're experiencing in Clone 4.4.33. Could you try updating the Clone server to that version (or newer), downloading and installing its Power...
Ah, of course. I assume the same thing persists when opening Clone in an incognito browser window? The UI retains a small state cache (which is cleared out in an incognito window or via a ctrl-F5 hard refresh), and I'm keen to rule out some odd transient error. In the meantime, it might be worth trying to do the same thing you're trying to do on the UI, but through PowerShell instead (e.g. with New-SqlCloneImage). This would rule out a functional issue on the agent, and should unblock you while the UI issue is tracked down. / comments
Ah, of course. I assume the same thing persists when opening Clone in an incognito browser window? The UI retains a small state cache (which is cleared out in an incognito window or via a ctrl-F5 h...
For general reference, we took this to support@red-gate.com and determined that, after deleting an old agent and installing a fresh one on a machine with the same machine name and SQL Server instance names (i.e. a VM refresh), the associated SQL Server instances weren't getting hooked up to the new agent. We'll be looking to improve Clone's behaviour here, but as a workaround, destroyed agents can be cleaned up with the Remove-SqlCloneMachine cmdlet, which should make all this behave more sensibly for now. If that's done after the agent is destroyed, but before the new one is installed, this issue shouldn't arise. / comments
For general reference, we took this to support@red-gate.com and determined that, after deleting an old agent and installing a fresh one on a machine with the same machine name and SQL Server instan...
Looks like the agent is online and happy from that - just the web UI doesn't agree. I'll have to identify some diagnostic steps to help us figure out why. In the meantime, to confirm that the agent is functioning normally, could you try creating a clone or image using that agent's SQL Server instance(s)? / comments
Looks like the agent is online and happy from that - just the web UI doesn't agree. I'll have to identify some diagnostic steps to help us figure out why. In the meantime, to confirm that the agent...
That's unusual. Could I ask you to use Clone's PowerShell cmdlets to help diagnose this? (The module can be downloaded from the UI's settings page.) The Get-SqlCloneMachine cmdlet should return information on your agents, including their state. Ordinarily the web UI would be a perfectly good source of information for this, but it seems as though in this case it's disagreeing with itself. / comments
That's unusual. Could I ask you to use Clone's PowerShell cmdlets to help diagnose this? (The module can be downloaded from the UI's settings page.) The Get-SqlCloneMachine cmdlet should return inf...
Great, I'm glad you were able to get things sorted. / comments
Great, I'm glad you were able to get things sorted.
Apologies for the delay on getting back to you on this! Ordinarily the database files would be restored from backup directly into the image destination, so for them to appear in the temporary directory is unusual. The best path forward here is probably to get in touch with our support team directly (support@red-gate.com) so that we can arrange to have a look at the agent log files and see what's been going on. / comments
Apologies for the delay on getting back to you on this!Ordinarily the database files would be restored from backup directly into the image destination, so for them to appear in the temporary direct...