Comments for Steve Hart http://www.hartsteve.com "The best prophet is common sense, our native wit." - Euripides Sat, 13 Mar 2010 22:39:47 +0000 http://wordpress.org/?v=2.6.2 Comment on SharePoint Document Management - Folder Discontent by Brice http://www.hartsteve.com/2009/06/16/sharepoint-document-management-folder-discontent/#comment-7739 Brice Tue, 23 Feb 2010 23:10:54 +0000 http://www.hartsteve.com/?p=170#comment-7739 I know I am late to this party, but you could do something like that using a migration tool. I am currently looking into one by Metalogix, here: http://www.metalogix.net/Products/FileShare-Migration-Manager-for-Sharepoint/ They have several different products that interface with various systeme: File System, Documentum/eRoom, custom web-based DMS, etc. They are very helpful and service oriented, as well. My task is to index a folder full of files (and subfolders), extract path metadata and merge it with an Excel spreadsheet that contains a 'Master Document List, with more metadata. Then the whole lot needs to be crammed into Sharepoint. Supposedly this will help do the trick (recommendations from a good friend), but I haven't had the opportunity to check it out fully, yet. I am also looking into storing documents externally with StoragePoint. Seamless integration for end-users. They never know the difference, and network storage/SAN is cheaper than more SQL boxes, processors, licenses, management, etc. This is a pretty good product: http://www.storagepoint.com Good luck, all. I know I am late to this party, but you could do something like that using a migration tool.

I am currently looking into one by Metalogix, here: http://www.metalogix.net/Products/FileShare-Migration-Manager-for-Sharepoint/

They have several different products that interface with various systeme: File System, Documentum/eRoom, custom web-based DMS, etc. They are very helpful and service oriented, as well.

My task is to index a folder full of files (and subfolders), extract path metadata and merge it with an Excel spreadsheet that contains a ‘Master Document List, with more metadata. Then the whole lot needs to be crammed into Sharepoint. Supposedly this will help do the trick (recommendations from a good friend), but I haven’t had the opportunity to check it out fully, yet.

I am also looking into storing documents externally with StoragePoint. Seamless integration for end-users. They never know the difference, and network storage/SAN is cheaper than more SQL boxes, processors, licenses, management, etc. This is a pretty good product: http://www.storagepoint.com

Good luck, all.

]]> Comment on SharePoint Document Management - Folder Discontent by Steve http://www.hartsteve.com/2009/06/16/sharepoint-document-management-folder-discontent/#comment-7657 Steve Wed, 23 Sep 2009 21:00:23 +0000 http://www.hartsteve.com/?p=170#comment-7657 Mark, your suggested migration workflow (from shared folders) into SharePoint with preservation of folder path as metadata is a superb concept. I don't think it would be that difficult at all to write a component to do that. Of course, the nature of shared folders is that someone may have placed a document in the wrong folder and ... it would end up with the wrong metadata in SharePoint but for the vast majority of documents I think your migration idea would work very well. And, another big benefit of your approach is that with SharePoint Enterprise Search, the folder metadata value can be indexed and can subsequently be searched. So, for users accustomed to working in their shared folders for years, they can simply go to the SharePoint search field, and search for documents containing a certain folder name by searching against the folder metadata property. Brilliant! Mark, your suggested migration workflow (from shared folders) into SharePoint with preservation of folder path as metadata is a superb concept. I don’t think it would be that difficult at all to write a component to do that. Of course, the nature of shared folders is that someone may have placed a document in the wrong folder and … it would end up with the wrong metadata in SharePoint but for the vast majority of documents I think your migration idea would work very well. And, another big benefit of your approach is that with SharePoint Enterprise Search, the folder metadata value can be indexed and can subsequently be searched. So, for users accustomed to working in their shared folders for years, they can simply go to the SharePoint search field, and search for documents containing a certain folder name by searching against the folder metadata property. Brilliant!

]]> Comment on SharePoint Document Management - Folder Discontent by Mark http://www.hartsteve.com/2009/06/16/sharepoint-document-management-folder-discontent/#comment-7656 Mark Wed, 23 Sep 2009 17:56:32 +0000 http://www.hartsteve.com/?p=170#comment-7656 Yes, I faced the same issues--in spades! I had one dept with 1500+ documents in 300+ folders, and most definitely, the folder names were the metadata. Some folder names were as simple as "1", meaning from the taxonomy "Product = XYZ; Major Version = 1". The sub-folders "1", "2", and "3" would correspond to "Product = XYZ; Major Version = 1"; Minor Version = 1"; "Product = XYZ; Major Version = 1"; Minor Version = 2"; and Product = XYZ; Major Version = 1"; Minor Version = 3". My options were to move as is, or create and attach metadata like "Prod XYZ.1.1", "Prod XYZ.1.2", "Prod XYZ.1.3" to 1500+ documents. I WISH there was time to build a tool as follows, but maybe the concept can help: One Workflow runs against a document. It can grab the path (like Products/XYZ/1/3/specs.doc") and store it into a new field (not needed in the view) with the document. A second field decomposes the path based on the location of each slash, and synthesizes a metadata value (like "Prod XYZ.1.3"). Copy that computation to a third field as a SLOT, and voila, that document is now tagged with the metadata value "Prod XYZ.1.3". Then, create a view that groups by the metadata and ignores the folders. FOR EXTRA CREDIT, change the document name from "specs.doc" to "Prod XYZ.1.3 Specs.doc". Yes, I faced the same issues–in spades! I had one dept with 1500+ documents in 300+ folders, and most definitely, the folder names were the metadata. Some folder names were as simple as “1″, meaning from the taxonomy “Product = XYZ; Major Version = 1″. The sub-folders “1″, “2″, and “3″ would correspond to “Product = XYZ; Major Version = 1″; Minor Version = 1″; “Product = XYZ; Major Version = 1″; Minor Version = 2″; and Product = XYZ; Major Version = 1″; Minor Version = 3″.

My options were to move as is, or create and attach metadata like “Prod XYZ.1.1″, “Prod XYZ.1.2″, “Prod XYZ.1.3″ to 1500+ documents.

I WISH there was time to build a tool as follows, but maybe the concept can help: One Workflow runs against a document. It can grab the path (like Products/XYZ/1/3/specs.doc”) and store it into a new field (not needed in the view) with the document. A second field decomposes the path based on the location of each slash, and synthesizes a metadata value (like “Prod XYZ.1.3″). Copy that computation to a third field as a SLOT, and voila, that document is now tagged with the metadata value “Prod XYZ.1.3″. Then, create a view that groups by the metadata and ignores the folders.

FOR EXTRA CREDIT, change the document name from “specs.doc” to “Prod XYZ.1.3 Specs.doc”.

]]> Comment on ZoomIt Damn It! by Jame Healy http://www.hartsteve.com/2009/09/07/zoomit-damn-it/#comment-7650 Jame Healy Fri, 11 Sep 2009 02:42:40 +0000 http://www.hartsteve.com/2009/09/07/zoomit-damn-it/#comment-7650 Very cool ... just downloaded it to try it. Quite good. Not that I demonstrate a lot of softare, but the install and use is "pretty much" idiot proof. Very cool … just downloaded it to try it. Quite good.

Not that I demonstrate a lot of softare, but the install and use is “pretty much” idiot proof.

]]> Comment on 0.0.0.0 Default Gateway by Bernard Macias http://www.hartsteve.com/2009/07/09/0000-default-gateway/#comment-7649 Bernard Macias Wed, 09 Sep 2009 17:09:41 +0000 http://www.hartsteve.com/?p=192#comment-7649 This a is weird issue, I am glad I am not the only person experiencing this. You can also resolve this issue using 'netsh interface ip set address name="Local Area Connection" static ' This a is weird issue, I am glad I am not the only person experiencing this. You can also resolve this issue using ‘netsh interface ip set address name=”Local Area Connection” static ‘

]]> Comment on The Gemini Approach by Steve http://www.hartsteve.com/2009/06/19/the-gemini-approach/#comment-7648 Steve Tue, 08 Sep 2009 01:32:30 +0000 http://www.hartsteve.com/?p=189#comment-7648 According to everything I've seen/heard about Gemini at the time, it is OLAP. But, then, I'm not an OLAP expert. Perhaps this article OLAP Report article will help provide the answer: http://www.olapreport.com/Comment_Gemini.htm. According to everything I’ve seen/heard about Gemini at the time, it is OLAP. But, then, I’m not an OLAP expert. Perhaps this article OLAP Report article will help provide the answer: http://www.olapreport.com/Comment_Gemini.htm.

]]> Comment on The Gemini Approach by Dick http://www.hartsteve.com/2009/06/19/the-gemini-approach/#comment-7645 Dick Wed, 02 Sep 2009 19:54:27 +0000 http://www.hartsteve.com/?p=189#comment-7645 But is Gemini REALLY an OLAP tool? It strikes me at this stage as just a replacement for MS Query for supplying Aggregations of Relational data through Excel Pivot Tables (??) Please tell me I'm wrong.... Dick But is Gemini REALLY an OLAP tool? It strikes me at this stage as just a replacement for MS Query for supplying Aggregations of Relational data through Excel Pivot Tables (??) Please tell me I’m wrong….

Dick

]]> Comment on Adobe Photoshop Scripting by Brett http://www.hartsteve.com/2008/09/26/adobe-photoshop-scripting/#comment-7642 Brett Thu, 27 Aug 2009 12:28:59 +0000 http://www.hartsteve.com/2008/09/26/adobe-photoshop-scripting/#comment-7642 I would love a full size copy of that image if you would be so kind. I have to do some training on Microsft SharePoint and that graphic goes perfect with my search conversation. Please forward to my email, if you don't mind sharing. Thanks Brett I would love a full size copy of that image if you would be so kind. I have to do some training on Microsft SharePoint and that graphic goes perfect with my search conversation.

Please forward to my email, if you don’t mind sharing.

Thanks
Brett

]]> Comment on SharePoint Document Management - Folder Discontent by Bharath http://www.hartsteve.com/2009/06/16/sharepoint-document-management-folder-discontent/#comment-7640 Bharath Tue, 11 Aug 2009 14:20:10 +0000 http://www.hartsteve.com/?p=170#comment-7640 Hi Guys, I have a Share folder which has to be moved to a document library and the size is 13.3 gb with 19500 files and 980 folders. I'm moving this to sharepoint and i am worried about the performance and the querry time required whenever i search for or sort or filter datas. Just lemme know the best practice or some links.. Thanks, Bharath Hi Guys,

I have a Share folder which has to be moved to a document library and the size is 13.3 gb with 19500 files and 980 folders.
I’m moving this to sharepoint and i am worried about the performance and the querry time required whenever i search for or sort or filter datas.

Just lemme know the best practice or some links..

Thanks,
Bharath

]]> Comment on SharePoint Document Management - Folder Discontent by Jeff http://www.hartsteve.com/2009/06/16/sharepoint-document-management-folder-discontent/#comment-7630 Jeff Fri, 17 Jul 2009 21:08:18 +0000 http://www.hartsteve.com/?p=170#comment-7630 I am not sure that Mike is correct. The MS guidance in "Planning and architecture for Windows SharePoint Services 3.0 technology, part 2" seems to indicate they are referring to performance as a function of total library size. They have some nice graphs showing performance (measured in transactions per second) for a flat library that shows the 200, 2000 and 4000 performance "cliffs" clearly. There is also a comparison of performance for folder views (500docs/folder) vs indexed views up to 1M total docs. They clearly indicate that "performance is better when folders are used." I am in agreement w/ the frustration that I sense from Steve as I try to begin a SP project. The entire community is cleared geared to abhor the folder and I see the benefits of the "tagged" doc approach of SP. But the built-in library performance limitations and MS's own advice drive the need for folders. The disconnect is expecially painful for me as I am new to the game and have a project w/ a known library size of 10k docs but there is a dearth of articles/guidance on how to implement a folder structure to deliver optimized performance of the product. Uugghh!! I am not sure that Mike is correct. The MS guidance in “Planning and architecture for Windows SharePoint Services 3.0 technology, part 2″ seems to indicate they are referring to performance as a function of total library size. They have some nice graphs showing performance (measured in transactions per second) for a flat library that shows the 200, 2000 and 4000 performance “cliffs” clearly. There is also a comparison of performance for folder views (500docs/folder) vs indexed views up to 1M total docs. They clearly indicate that “performance is better when folders are used.”

I am in agreement w/ the frustration that I sense from Steve as I try to begin a SP project. The entire community is cleared geared to abhor the folder and I see the benefits of the “tagged” doc approach of SP. But the built-in library performance limitations and MS’s own advice drive the need for folders. The disconnect is expecially painful for me as I am new to the game and have a project w/ a known library size of 10k docs but there is a dearth of articles/guidance on how to implement a folder structure to deliver optimized performance of the product. Uugghh!!

]]>