When you click New Workspace in Groove 2007, you have three options for the type of workspace you want to create: Standard, File Sharing, or Template. So what’s the difference? The Template option is simply a Standard Workspace with a custom toolset. The differences between Groove Standard workspaces and Groove File Sharing (GFS) workspaces are more complicated.
First, all Groove workspaces, of either type, use the same underlying Groove technologies for determining which members are online, identifying changed data, and sending and receiving data across the network. However, beyond that, Standard and File Sharing workspaces have many differences.
Capabilities
A Standard workspace can support many Groove tools -- Discussion, Calendar, Forms, Pictures, and Files, to name a few. A File Sharing workspace keeps a Windows folder synchronized with another computer or computers, so it approximates only the capabilities of the Groove Files tool.
Access
In a Files tool in a Standard workspaces, all content it is kept in Groove. For example, if you have a Word document in a Standard workspace, you must open that document from the workspace to view or change it. When you open the file, Groove creates a temporary, unencrypted copy of the file and passes it to Word. When you save the file in Word, your changes are saved to the temporary copy. The next time you click on a Groove window, Groove will detect the changes to the temporary file and ask if you want to save those changes back into Groove. When you shut down Groove, Groove deletes the temporary copy that it handed to the application, and the file is again only accessible from within Groove.
In a File Sharing workspace, the synchronized files are part of your standard Windows file system, and you can access them directly from other applications and perform operations on them in Windows Explorer. Groove does not encrypt the files on disk, on in any way act as a gatekeeper to those files. (However, since the workspace synchronization uses the Groove transport mechanisms, they are still encrypted whenever Groove sends them over the network.) This outside access is more convenient in some situations, but it also introduces more ways that data can be altered or removed from the workspace in error. It also limits the extent to which Groove can distinguish new data from data that has been moved or renamed, so under some condition, simple file operations can lead to retransmitting large amounts of data.
Invitations
When you accept an invitation to a Standard workspace, the Groove installation that issued the invitation sends you the entire contents of the workspace as it exists on the inviting computer. If the inviter’s copy of the workspace contains Files tool folders that have restrictive Download options, this may not include all files.
When you accept an invitation to a GFS workspace, the Groove installation that issued the invitation sends you an index of the folder and its subfolders. Your copy of Groove then fetches the files and their contents. Again, if the inviter’s copy of the workspace contains folders that have restrictive Download options, this may not include all files.
Size Limitations
When a Standard workspace exceeds 2 GB in size, you cannot invite new members or new computers to it, however, existing members will continue to receive updates to workspace data.
When a File Sharing workspace exceeds 2 GB in size, it will no longer synchronize with the local folder, existing members will cease to receive updates to workspace data, and the workspace properties will display a synchronization error on the Status tab. Due to the invitation behavior of File Sharing workspaces, you can still send an invitation to a workspace that has exceeded this size. If the invitee accepts it, they will receive an error about the size, but can choose to receive only file stubs, and from those, can download individual files. However, any changes they make to the files will not be propagated, because the workspace is no longer being synchronized.
Backup
A Groove workspace that exists on multiple computers has some built-in resistance to mechanical failure. For example, if you lose workspace data due to a hard drive failure, you can retrieve that data from other workspaces members once you reinstall Groove. However, other data threats exist, and you should still have a plan for data backup.
In a Standard workspace, because of Groove data encryption, you should archive workspaces from within Groove. For each workspace that you want to save, right click on the workspace, select Save As, click Archive, and then follow the prompts. These archives are useful if a workspace member deletes or changes needed workspace data, or deletes the entire workspace.
Because a File Sharing workspace uses a standard Groove folder, you can back up the files in the folder using normal file backup methods. However, avoid backup programs that might alter the file in a manner that causes Groove to see it as substantially changed and retransmit it to all members. Folder backups are useful if a workspace members deletes or changes needed workspace data, or if a Windows user or program deletes or changes files in the folder.
I appreciate you spending sometime on explaining this distinction. One question that has been nagging me is why there is this distinction of a File Sharing Workspace and a Standard Workspace particularly if they leverage the same technology. Why couldn't the Standard Workspace File Tool work in the same way as the File Sharing workspace? It seems the real value of this model is minimizing the number of manual steps involved in a person sharing information.
Also, do you know why there is a 2GB limitation on the workspace size? If it's all P2P what difference does the container size make?
Hi folks, just curious if you had any thoughts about my earlier post. What we've been doing here for our projects has been using the Groove File Sharing Workspace and Microsoft SyncToy on a Windows Scheduler Task to upload changes to a Sharepoint site. This sort of adds the Sharepoint connector part of the Standard Workspace but obviously misses the other tools like Issues, Calendars etc.
Hi Bryan,
The technology for transport and awareness is the same, but the technologies for managing the files are not. Groove added the File Sharing workspace type because there was a demand for files that could be accessed outside of the tool, but that required relinquishing a lot of control over the tool contents. Also, at the time, the on-disk encryption benefits of Groove were a major selling point, though the importance of that feature has probably declined since more sophisticated encryption methods have been added to Windows at the file system level.
It sounds like you'd like a shared folder implemented as a tool, so it could be included in a workspace with other tools. I suspect that it would have been implemented that way if it had been practical to do so, but I don't know what actual issues there may have been with that.
Thanks for sharing this background. The workaround that we've using is to have separate Groove Shares, a Workspace where we manage meeting minutes, discussion threads and other project forms (issues, etc) and a File Share (in fact we usually have two, one Internal and one External).
Question: How does Groove manage synchronization of large files. One of our users has a 12MB Excel file (don't ask!) and it autosaves every 10 minutes, the problem he was finding was that sometimes the auto-save would fail because the file was locked (since it was taking so long to synch and because it synched everytime he saved the file). Are there any suggestions for sharing large files in Groove?
I can't seem to get this question answered by researching anywhere. So I'm actually posting the question as I need a clear answer from some kind of an authority on the subject.
Does the File Tool allow for file synching across machines on a 64 bit OS?
I know that File Sharing Workspaces don't work and there's no hope for that. But I really need to know without having to actually install a 64 bit OS to test it, whether or not the File Tool syncs content across machines successfully in an OS such as Vista 64 bit.
My business relies on Groove File Sharing Workspaces. And I've read that around 40% of the latest laptops being sold at big box stores are being shipped with Vista 64 bit. My business employs subcontractors who are required to use their own computers to complete work for me. Someday soon, some new subcontractor is going to come along with a machine that has Vista 64 bit on it unbeknownst to the subcontractor. And I'm going to have to deal with it. It won't be such a problem if we can switch to Standard Workspaces. But jeez, if those things don't even work then I'm going to have to have a major infrastructural change that will affect 15 employees. Yeesh!
Thanks a lot for your help.
Camineet
Hi - I stumbled across your blog looking for help with sharing files in Groove. A few of us share files, which we all work on, periodically. Is there any way to "flag" or indicate that the file is currently open by someone else. Often we end up with multiple copies of a file b/c two or more people were working on it at the same time, unknowingly. Any advice?
Hi Camineet!
Yes, you can use the Files tool in a Standard workspace on a 64-bit Vista system.
Basically, the way an application accesses user files completely changes in 64-bit systems, so extending support for File Sharing workspaces to those systems would involve rewriting most of that functionality. For the moment, the Files tool is the best substitute in Groove.
No, there is no automatic way to do this in Groove. To do it manually, you can keep an associated Discussion tool or Forms tool and leave check in/check out notifications. For more control, we recommend Sharepoint.
Thanks for answering my question about 64 bit systems.
Now I have another question I hope you can help with. My company runs File Sharing Workspaces. We currently run about 30 of them, and as we hire more employees, the number keeps growing.
I have read your post about keeping the number of File Sharing Workspaces under 50 and have become concerned about our future with these kinds of workspaces. Thus far, with quad or dual core processors and 4GB of RAM, we aren't experiencing any problems.
I am however strongly considering adding new employees with Standard Workspaces, and slowly migrating the existing employees over to them. This is primarily to preserve the scalability of my company. I also plan to purchase a low-powered notebook such as the Samsung NC10, and do not want experience crippling Groove performance.
So my question is, what is the real difference in system resource usage between File Sharing Workspaces and Standard Workspaces. Can you offer some kind of percentage measure in processor usage or something like that?
I can share this: I have done some speed tests between my office in China and my office in the US, and Standard Workspaces transfer files 80% or 1.8 times faster than File Sharing Workspaces. I'm not sure if this has to do with the internet or network bandwidth usage differences between File Sharing Workspaces and Standard Workspaces, or if has to do with system resource usage differences (processor and RAM) between File Sharing Workspaces and Standard Workspaces. It seems like it may be the latter, as I have watched File Sharing Workspaces transfer data by looking at the little upload arrow at the bottom of the Launchbar, and then have watched as there is a lag of many seconds before the file will actually show up at it's destination once the uploading data indicator arrow reduces to zero (I used LogMeIn to watch the two systems in China and the US transmit and receive files when I performed these tests). With Standard Workspaces, there is no lag. After the data is finished transmitting, the file shows up instantly.
I'll close by saying that Groove has allowed me to do some amazing things with my company and my life. I utilize the principles in the 4 Hour Work Week, and Groove has been a key contributing factor in my success in doing so. I love this program. I read somewhere that it's the baby of some guy named Ray Ozzie who is (or was) some kind of Microsoft super-talent. I'd be interested to know how some of the more recently released competitors such as Sugarsync and DropBox stack up in terms of performance. But I'd just bet that although Groove isn't perfect in terms of version handling and transfer speeds, etc., that it handles those kinds of things more robustly than competitor products. And save for browser based access to files, Groove seems to have a better feature set. For example, Windows Live FolderShare allows only 15 as the maximum number of libraries - pathetic. I actually switched to Groove for this very reason.
Anyway, I love Groove and I'm surprised there isn't more of an online user community. Your blog is pretty much all there is. Thank you for it.
Best,
Hi Camineet,
I'm afraid I don't have that sort of analysis available. You could try an advisory support case, but it might be beyond even that, since there are so many factors that affect processing and transfer speed. I will put up a pointer in the blog, though, in case someone else wants to contribute here, and you could try posting in the Groove newsgroup (http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.groove&cat=en_US_792FBD1E-56F4-C0D4-D4DB-2249A9A182A6&lang=en&cr=US) to see if anyone else has input.
The lag is curious. File Sharing workspaces are more prone to spurious transmits than Standard workspaces, but both use the same components to transmit data, including the encryption and compression processing. Perhaps there is a virus scanner on the receiving end intercepting the files for the File Sharing workspace, and they do not appear until processed? Unless you have virus scanning enabled in Preferences/Options, the Standard workspace files would not be scanned.
In terms of processing needs, Standard workspaces have the extra step of encrypting data for storage and decrypting it for use. File Sharing workspaces, however, need to monitor file system events. My guess would be that there is higher processor usage to open or save a file in a Standard workspace, but higher usage when idle for a File Sharing workpace.
Great answer. You've really given me some clarity on the factors that contribute to Groove performance issues.
I'm still faced with a decision that I'm having a tough time making. Let me ask you this way:
I expect to have more than 50 workspaces in the future. Given this expectation, how strongly would you recommend that I switch to using Standard Workspaces?
Put another way: I have read that there can be performance problems when having more than 50 File Sharing Workspaces. Do you think that the same problems can arise with more than 50 Standard Workspaces?
I understand that Standard Workspaces do not require event monitoring. Does this mean that a system should be able to accommodate many more than 50 Standard Workspaces without there being a continuous or burdensome system resource draw?
Anymore commentary on this issue would be much appreciated. Thanks a lot.
First, I apologize for the delay in approving your comment. Anonymous comments are set to require approval, and I was out of the office yesterday. To avoid that delay in the future, you may want to create a user account.
I would definitely recommend switching to Standard workspaces where possible. First, the File Sharing workspace resource problem is not a performance problem -- Groove becomes completely unresponsive when you go over the limit for your system. Second, I know anecdotally that we have had customers successfully using around 100 workspaces when those workspaces are mostly Standard workspaces.
As to at what point you would have a burdensome resource draw, I really can't predict that. Resources used by standard workspaces depend on how many members the workspaces have and the level of activity in those workspaces, as well as the capabilities of your system. Furthermore, very few customers who contact support use workspaces in those quantities, and I doubt anyone does so internally (outside of testing), so there is very little data on that usage pattern. (As a point of reference, I currently have 32 workspaces, 3 of them File Sharing workspaces.)
Thanks again.
I have made the decision to add new employees as Standard Workspaces, and have rolled out this decision to my company.
However, I'm really conflicted about it because of the poor backup options with Standard Workspaces.
Not being able to rely on Windows' baked in previous versions functionality as a backup system along with Mozy might be more than I can stand.
I don't know about Vista because I skipped it, but have you seen the previous versions function in Windows 7? I am going to have a really hard time living without this. And I can't use Mozy to backup my files either? I have to manually archive the Workspaces? This is really tough to swallow.
With Mozy running, if I terminally screw up a file in a folder that's a File Sharing Workspace, I can just right click in the folder and browse previous versions from Mozy's servers. This functionality has saved me time and embarrassment once before.
With Windows 7's previous versions function, I can do the same. This functionality has also saved me time and embarrassment once before. Windows 7's previous versions functionality uses Windows 7's shadow copy something-or-other to store previous versions that are only incrementally different. So the HDD usage to preserve and make available numerous previous versions of files is not burdensome.
So now enters the only way to backup Standard Workspaces - archiving. Blecch. True enough, I can automate the process with Personal Groove Backup from ThreeWill. However, the archives are full-size backups. And I have to manually go into the backup locations and preen the automatically backing up workspaces from very far back so as to not fill up my hard drive. This is just ugly.
I'm telling you, I was in a phone meeting with an employee the other day, and I completely screwed up a shared spreadsheet when editing it - deleting an important piece of information and not being able to retrieve it. It was a File Sharing Workspace, so all I had to do was right click the folder and go to Properties/Previous Versions. And then I was able to select a version of the file from 5 minutes previous. I retrieved the information that I mistakenly deleted, and continued in the meeting without the employee ever knowing about my screwup.
I'm about two months away from getting a netbook - the kind with the 1.6Ghz Atom processor. And I plan to do some traveling with it. If it weren't for my plans to use this kind of low powered device, I would definitely be sticking with File Sharing Workspaces. And I still may try to stick with them. I might get the device and see how far I can push it.
"When Groove starts up, it creates for each GFS workspace a system event that provides it with the means to monitor file system operations in that synchronized folder. If Groove runs out of available events, the problem occurs, and Groove enters a loop that eventually consumes all processor cycles."
Let me ask you this: You say that it's not a performance problem. By that I'm assuming you mean that it's an available event usage problem.
So, is it that this problem is only related to startup? It sounds like the problem is caused because Groove creates system events at startup that can exceed the available events. Does this mean that Groove holds these system events for its use the entire time Groove is running? Or does it only use them at startup? If that were the case, then maybe as long as Groove doesn't become unusable upon startup, that after it's done with its initial syncing of workspaces, it should run using a similar amount of resources whether it's using File Sharing Workspaces or Standard Workspaces. What do you think?
Just wanted to add that our workspaces only contain between 1 and 50MB of data. Never any more than that. Is the event issue affected by the size of the workspaces?