Note: This article is obsolete after the release of PowerFuse 2010, which includes a built-in File Sync feature. Stay tuned for a new article on this feature.
This article covers how you can set up an environment which will present the same homedrive to the user no mater where they are logging in from; workstations, laptops, citrix, terminalservers – it doesn’t matter, they will see the same drive with the same contens. There is a simple description of this in the RES KB article Q200070 (you’ll need a login to the RES portal to access it). The article below is an enhanced approach to handling homedir sync.
So, first things first – let’s face it: It’s quite rare to come across somebody who has gotten the built in Offline Folders in Windows to work for them as they want, among those even fewer yet who are happy with it. So that’s why this solution is absolutely not involving those pesky MS offline folders.
Instead, we are going to use PowerFuse to take care of these things for us. As usual, the Fast-Track route is at the end of the article
Step 1 – Map the homedrive through PowerFuse.
If they’re not mapping the drive through as script or a policy, many admins set the homedrive in the AD, for the user as drive whatever X: being mapped to your-serverusershare$%username%. This is all fine, except it doesn’t really do much for us in an environment where users could be both offline and online. There is one pontential caveat to not using AD to map the homedrive – this hasn’t been verified – but at least in the old days, Multiwin in terminal servers relied on the home directory to find out where it should store the user specific windows folder. So, there is a potential risk that this might screw up some legacy app. Reports from the field suggests that it overall seems safe, but test it anyway in your environment to be sure.
So, what’s the alternative? Well, PowerFuse will do the mapping just nicely for you. And by doing the mapping in there means you can have all your company’s network drives in one single place, where they are documented and maintained easily. Just fire up your RES PowerFuse console and go to Configuration Management | PowerLaunch | Drive and Port mapping. Create a new mapping which looks like this:
Note: It’s important that the Requred Connection State is set up correctly to Online, as we don’t want the network drive to be mapped when a laptop is off the network. Right, that takes care of that, but what about the offline state then?
Step 2 – Subst the homedrive when offline.
If Subst leaves you looking like a questionmark do not despair, it’s a remnant of the old DOS days, enabeling a user to create a sort of local drive mapping. Effectively you could create an H: drive pointing to a folder called c:offline. Of course as a PowerFuse admin, you don’t have to bother with the commandline as the nice folks at RES have put in a feature for us to deal with this. Go to Configuration Management | PowerLaunch | Drive Substitutes. Here we will create a new subst which looks like this:
Again note that the Requred connection stateis now set to online. You may at this point consider adding access control, as you perhaps may not want all users to have access to homedrive data when offline. Now we have created the two basic mappings which together will create the H: drive no matter connection state. There is however still the matter the %systemdrive%offline%username% folder. This is created so the computer actually can be used by multiple users. Each user will then have their own local cached copy of their homedrive data. Additionally, if you hide the C: drive of the computer then the individual users will only have access to their own files. The drive’s contens will look exactly like when mapping to a common UNC path for user home directories on a server. The offline folder here is merely a plain vanilla folder on the local drive of the laptop, we’ll get around to making it shortly.
Step 3 – Create a PowerZone to identify mobile computers
As mentioned before, the offline folder we want is no big deal itself; we can just execute an MKDIR/MD command to do this. The trick is that we don’t want the folder made on computers that never leave the network anyway, such as workstations and terminal servers. We don’t want user data floating around where it’s
In order to serve this purpose, we want to create a PowerZone which can help us identify if we (the user) are running on a portable computer or not. Also we do not want the syncronization to happen on non-portable computers.
Anyway – Go to Configuration Management | PowerZones and create a new PowerZone. Call Laptops for example. It could look like the one below. There are tonnes of rules to help you define what may be exactly right for you, so consider carefully what would make the most sense for your installation. The buildingblock you will find in the Fast-Track section has a somewhat different PowerZone definition. The one shown below is using the Hardware Requrement | Chassistype rule. A note on this specific rule. You can add multiple types of chassis types. The rule will be parsed with a boolean OR, meaning just one or more of the selected chassistypes have to be present for the rule to return True.
Okay, so now we can know when the user is on a computer which need the offline folder. This will come in handy as we can now proceed to create the external task.
Step 4 – Create an external task to make the offline folder.
Let’s make that offline folder: We go to Configuration Management | PowerLaunch | External Tasks. Note that these tasks are executed at logon per default. It is however possible to tweak the tasks to execute at other times like logoff or even when a session has been refreshed. You do that by changing the Run task field shown below. Create a new external task so it looks like this:
Also it is important to make sure that this task is only executed when we are on computers where we want it, namely laptops. That’s why we created the PowerZone in the previous step. Go to the Access Control tab of the external task you’ve just created and add the laptop PowerZone to the lower part of the Access Control dialog.
When you hit edit, the Location window as shown above will appear. Here you can also reverse the PowerZone logic using the checkmark “Apply settings when selected PowerZone is NOT applicaple”. Again, don’t get lost in the possibilities, a healthy approach to doing advanced stuff in PowerFuse is always to keep in mind what you need to accomplish.
Step 5 – Set up syncronization events.
What we need to do now is to configure the actual syncronization of the data between then network folder and the offline folder. You can use any tool you like here, be it RoboCopy, SyncToy (maybe an updated article with this one later on). For the time being, here’s an example using the built in pwrsync.exe which is a part of PowerFuse. Now just to be clear on a couple of items
- Pwrsync is a legacy component back from the 7.x of PowerFuse
- It’s original purpose back then, was to syncronize PowerFuse 7.x fileshare-based configuration databases, i.e. it was not purpose built for what we’re going to use it for here.
- It appears only to sync one way, as in contrast to MS SyncToy which can do bi-directional sync in one go
- It remains to be seen if this utility will be included in future versions of PowerFuse, hence this article might get an overhaul in the future.
Either way for now – pwrsync.exe does the trick just nicely. You’ve already paid for it, so we might as well put it to good use. As mentioned in the beginning, RES’s kb 200article elaborates on the commandline parameters of pwrsync. With that out of the way, let’s talk about when we want to syncronize. It’s up to you eseentially however it’s advisable to consider these three events to trigger a sync:
- Logging on: Sync the offline folders up against the network drive
- Logging off: Synct the network drive to the offline folder
- Manual activation by the user. This will provide the users with an icon in their start menu which will trigger a sync to the offline folder on the laptop (a kinda “hey-sync-my-stuff, I’m-about-to-leave”)
The first two events are easy. We go to Configuration Management | PowerLaunch | External Tasks, and create two new tasks. The respective commandlines should look like this:
- Task #1: “%RESPFDIR%pwrsync.exe” /fullsync “%reshomedrive%” “%systemdrive%offline%username%” /online /log /title=”Please wait while your %reshomedrive% is syncronized to your laptop”
- Task #2: “%RESPFDIR%pwrsync.exe” /fullsync “%systemdrive%offline%username%” “%reshomedrive%” /online /log /title=”Please wait while data from your laptop is synced back to your %reshomedrive% drive”
Note: The %RESPFDIR% is an environment variable which PowerFuse implements. The default value of it wil point to your %programfiles%res powerfuse folder. Also note the usage of the %reshomedrive% variable. This env. variable is being set by PowerLaunch. Have a look at the technote here for a reference on how to set it up. The external tasks above, should be configured to look like this:
Note above how we’ve configured the app only to run at logoff, when there is a network connection. Also we’ve configured the ext.task to wait at most for 30 secs , if the sync command should get out of whack somehow. That way we ensure we won’t hang the logoff process.
Above, note how the Run task field has been set to At logon after other actions. This is done as it doesn’t make sense to attempt to sync any new offline data up to a network drive which hasn’t been mapped yet.
In both examples above, note how the command is configured to run hidden. Although it seems like a good idea, this checkbox does unfortunatly not have any effect on the PowerSync.exe utility as it completely ignores all polite requests to STFU… (that being said, it’s not entirely certain if MS Synctoy is any more happy about running hidden) Anyway, perhaps it’s not such a bad idea that the users can see that something is happening. Besides this, the tasks won’t try to run if we haven’t got a network connection, as there would be no point to this. It’s being governed by the setting in the Required Connection State field. Finally on both external tasks, we need to configure the Acces Control tab, to ensure that these two puppies only run when the user is using a laptop. Do exactly as described in the last part of step 4 above.
Step 6 – Set up a manual sync shortcut for the users.
Okay, this is the last leg of the tour. We want to create ourselves an icon which the users can click on to activate a sync. This is usefull if the user is about to leave and want to ensure all recently edited documents in his homedrive is on the laptop. Many users will simply close the lid of their rig and undock, but then it is ofcourse too late to sync as the network connection is likely gone. Istead the users should be told to click the Sync Button if they are in a hurry, or simply do not want to log their laptop off as they may prefer just to suspend/hibernate it.
In the Application Management node, we want to create a manual Sync icon. The application definition will look like this:
Don’t worry about the commandline parameters field below is being truncated a bit. It’s exactly the same as #1 before.
Also, it is important that we configure that this app isn’t available in any other environments than on the laptops. We wouldn’t want our users logging in on thin clients thinking they could sync something to them, right? In order to avoid such, we re-use the Hardware, Laptops PowerZone from before and assign the sync application to it. That configuration looks like this:
Once this has been configured, the next time a laptop user logs in, he will see an extra dialog box on the PowerFuse loader screen, cycling through the subfolders being synchronized. It looks like this:
Final thing which needs to be done, is to check the security on the %programfiles%res powerfusedata folder. Domain Users need to have read-write to this folder. If not, then pwrsync will just sit there and do f*ck-all for a minute or two. Don’t ask – that’s just the way it is. Anyway, a Wisdom module is provided to fix this particular problem, once the Buildingblock library is up and running.
Yup, you guessed it – your friendly neighborhood ResGuru has provided a Buildingblock to implement all of the above. The usual disclaimers apply. An article on how to make an empty test database quick and easy will be provided. Later.