Running WebDAV on your WFEs

So I’m going to start this blog post with a rant about SSRS, make reports outputtable to Excel 2007 format!

So with that said, we encountered a question poised to us from some of our users, “we have a report that is generated from SSRS that’s send to a file share. This has some KPI information we use in Sharepoint. It’s a manual process to get it converted and uploaded. Is there anything you can do to simplify this?”

If the SSRS was configured in Sharepoint Integration Mode, our lives would have been much simpler, but it wasn’t, so this is what we did.

AutoIT to the rescue. We created a script that will map 2 network drives, one to the network share where the files is sent from SSRS and the other to the Sharepoint document library where the file is to reside. Oh snap, can’t do a WebDAV connection to your Document Library in a SSL environment from the server! What to do?

We scratched our heads for a while and this is what we did, configured an AAM to point from localhost to our Sharepoint address. In IIS we added an additional entry in the advanced web site identification screen for the Sharepoint website that uses SSL. Then if we opened a command prompt and did a net use Z: \\localhost\sites\site\doclib, a successful mapped drive is created. Score!

After the drives are mapped with the AutoIT script, we excute a CMD file that copies the file from the file server to a temp directory, executes a VB script to convert the file to Excel 2007, copies the file to Sharepoint, then unmaps the drives and deletes the local files.

If you’d like to see examples of the script, let me know. What a pain in the…

Plurk This Post Buzz This Post Delicious Digg This Post Stumble This Post

Folders and metadata rehashed

My article about folders vs metadata has been posted on Enduser Sharepoint, visit http://www.endusersharepoint.com/?p=1707 for the article.

Plurk This Post Buzz This Post Delicious Digg This Post Stumble This Post

Folders and Metadata

This afternoon we started having a discussion on Twitter about metadata and folder structures within a document library. 140 characters was too few for me to really get into the nitty gritty so I’ll expound a bit.

I detest folders in libraries, although I have implemented a few folder based libraries because item level security required it. The only other time I’d consider folders is libraries where you start running into that 2000 item per view limit.

That being said, I had a user today need help organizing a library to show subfolders in the appropriate month order. To detail further, we have an environment where site collections are provisioned as desired and I serve in a capacity to oversee that process and consult and train owners of the site collections as needed. This was a case where I knew the right method, metadata and grouped/sorted views, was going to be the wrong path to take. I chose the work around to rename the folders so that it would sort properly instead of reworking their entire library.

Sometimes you have to choose your battles, after assessing the situation, I opted for the “wrong way”. If this was one of my power users, I’d definitely have pushed to the best practice method.

This is one of those great debate topics in Sharepoint and once you get it, you’re like “wow”. It really is an eye opener in administration when you make that synapse connection.

Plurk This Post Buzz This Post Delicious Digg This Post Stumble This Post

Blocking Sharepoint Designer – Highlevel Overview

There’s been a lot of buzz going around that Sharepoint Designer will be free in April.  This got me a bit worried as an administrator for our Sharepoint environment.  I’d like to have this user restricted as it can be potentially dangerous if permissions are not properly set.

I was talking with a technician about what would be done to block Sharepoint Designer from running.  Here is a high level view of how we would do it if we proceed down this path.

What would be done is a Group Policy would be created to block the exe or hash from running.  We run a blacklist of malware exes, so SPD would be added to that list.  We then would create an OU in Active Directory that would not inherit this group policy.  This would allow us to create a list of users in AD that should have access to the software.  This would allow us to have strict control over who can use it for design purposes.

We are still discussing whether or not we are going to implement this in our environment.  I am definately for it until we have an idea of the numbers of people interested in using it.

Plurk This Post Buzz This Post Delicious Digg This Post Stumble This Post