Going to ask this question, think the simple answer is no. 

Macrium currently has the ability to determine if a laptop is plugged in and if so set, it will not initiate a backup on battery.

Is the a simple way to do something similar only detecting is the laptop attached to the proper network. By proper I mean whenever you have installed your NAS. 

In other words it won't initiate if you are not connected to a network and it would interrogate the network and would not initiate, if say, you were connected to the coffee shop? 

Think this would be a nice feature unless someone has figured out how to achieve this already.

Not sure if this is what you are looking for, but if Reflect cannot find the destination drive for the backup (in your example, your NAS drive) it will abort the backup.  So not being connected to the network or at a coffee shop should both cause a failure to connect to the NAS drive.

Thanks. Not really what I was after. I don't want it to initiate because as you say it will fail. 

The reason the option exists about the battery is because Windows Task Scheduler itself supports that.  So if you enable that option on the scheduled task that you have Reflect create, then Windows performs that check, and the system is on battery power, then Reflect doesn't get called at all.  And I believe the recently introduced Macrium Task Scheduler now supports this as well in order to achieve feature parity with Microsoft's scheduler.  But WTS has no mechanism for saying, "Check whether this particular network target is available before calling Reflect".  That's something Reflect would have to do, and if Reflect is already going to get called, I don't really see the distinction between Reflect checking and quitting vs. starting the job and having it immediately fail, which will also quickly end the job.  I would argue that even if the former design were implemented, the job should still be logged as a failure rather than silently dismissed with no record -- so you'd still end up with a failed job in your log.  The only difference would be a very minor behavioral change under the hood.  Or am I missing something about what you're trying to achieve?

If you really want this, you could have Reflect generate a PowerShell script to call your job, and then customize that generated script to include a network check before proceeding with calling Reflect.  That would be simple to write, but in THAT case a failed network check would cause Reflect not to be called at all, so in that case you'd end up with no job failure logs from those attempts.  That could be dangerous, because Reflect will never say, "Hmm, you haven't had a backup in a while."

@jphughan depends how much effort you put into your script, powershell can generate a "backup skipped" email in such circumstances, I don't really see much point to this exercise though, or the advantage of that notification over one for a failed job.

Bearing in mind I actually agree with @jphughan this is pointless & would rather have failed jobs logged personally, the only time I see any advantage is if you want the postpone option to pop up, & want to not see it unless you're at the correct location.

Editing a generated batch job along the lines:


Tweaking the above to suit ought to get the job done, only calling Macrium if you're on the "right" network.  Again I suppose you could trigger some other outcome to alert you in the case also of ==False

So if you really want this you can, but I'd rather not see such a function as an included feature owing to the pitfalls @jphughan pointed out.

Skipping backup jobs silently is dangerous, as is only notifying on warnings or failures, people assume no news is good news, when circumstances can arise where actually the notification mechanism failed & backups are also failing silently.  You want to be notified of all outcomes in all cases, success, warnings, failures, and skipped jobs.

I would have just used the Test-Connection cmdlet to check for connectivity to a known hostname or IP (if either can be assumed to be unique rather than potentially existing on some other network that the PC might ever be on), but I guess the above works. Is there no native PowerShell cmdlet that will return an SSID, assuming the connection in question even uses WiFi?

And it seems like it would be easier to say, If Error, then Exit rather than If Successful, then Proceed, the latter is which requires placing the entire remainder of the script inside that If block.

Thanks gentlemen. 

Good discussion.

What I was trying to do in a Home environment is build a schedule that would run a backup, lets say a full every Saturday.  If the user had their device elsewhere I wanted Macrium to "suspend" the run until the user was reconnected at home. Yes the user could suspend but I was trying to get them out of the loop. If Macrium failed the user would still be in the loop to start when they next connected. 

For users such as yourselves or me this would be a non issue, for a teenager or young adult chances are this would be forgotten.

This really comes from my work days. Laptops would be out of the office, say a week, and when the user connected the backup would run. I think the backup initiation was embedded in login script. 

Thanks again for replying.



 

Wow !!

Thank you.

I will look into this Script builder wizard. I don't think I've ever seen that. Will read about "Duplicate"

Thanks again.

Happy to help. If you want to do this, right-click your definition file in Reflect, select Generate PowerShell Script, and in the Directory Synchronization section, specify your network target. Note that the replication portion of the script will not have access to network credentials stored in Reflect, since the replication is achieved by Robocopy. This means that the user account running Reflect scheduled tasks will need to have the appropriate access to the network target on its own, or else you’ll need to customize the script to mount the network target first, which means storing credentials in the script.

But if that’s not an issue, then go back and change your definition file to some local target instead, and then remove all schedule entries and recreate those on the script rather than the definition file, which you’ll find under the PowerShell Files tab.