SharePoint 2010 : How to retain Document ID while moving documents
<<< Cross posted from my main blog here >>>
Today’s water cooler discussion revolved around Document ID management system of SharePoint. It is a nice feature and can actually help to find the documents quickly and in a predicted manner. Basically you get a short URL in SharePoint for your document, rather than a cryptic one and SharePoint will find the document no matter where you moved it.
But there is a catch, it will be able to find it if you move it within the Site Collection. If you move it out of the site collection, a new Doc ID will be generated and assigned to the document. BOOM!! your short URL is pointing to nothing now.
So how do we move documents without changing their Doc ID?
Nuisances of starting developing Apps for SharePoint 2013–Summarized
Yesterday when I wrote about my experiences about starting to develop Apps for SharePoint 2013, I got some feedback to consolidate the steps. So here it goes…
In nutshell, you follow the blog here at TechNet and setup you developer machine with the required tools. Make sure you give a good read Step 4 Install Development Tools in the blog thoroughly and configure the configure the app domain isolation and services properly. Once the tools and services are in place, here are the steps that you need to follow to make sure you can start developing apps for SharePoint 2013, without issues.
- My farm setup is as below:
- Virtual machine with SharePoint 2013 Enterprise on Windows Server 2012 with 10 GB RAM + Visual Studio 2012 and Office Development Tools for VS 2012.
- SQL Server 2008 R2 with SP1 on Windows 2008 R2 virtual machine (yes, you need to have SP1 installed)
- Windows 2008 R2 virtual machine acting as Primary Domain Controller (PDC)
- Make sure your development user account is different from System Account. Ideally you should install SharePoint (and have the System Account) with least-privilege account and development with different account.
- Make sure your development user is having following permissions within SharePoint:
- User is part of Farm Administrators group
- User is part of Site Collection owners group
- User is local administrator on the SharePoint machine (just to avoid entering admin credentials for every UAC prompt, else not required)
- Make sure your development user is having DB_Owner permissions on the following SharePoint databases:
- Config DB
- Content DB (for the site collection where you are going to deploy apps)
- AppMng_Service_DB_{GUID} (where {GUID} would be a random GUID assigned to the DB name)
Once you are done with these steps, login into SharePoint development machine using development user credentials and start developing Apps for SharePoint 2013.
Happy Apps!
Nuisances of starting developing Apps for SharePoint 2013
Recently I was into a SharePoint 2013 overview training. Though the theory was fine, starting the actual App Development was a major hiccup, due to few changes that an experienced SharePoint developer would not expect.
As most of you would know by know, that SharePoint 2013 app development is supported in 2 ways:
- Napa tools development
Here the development environment is hosted inside a browser and no local installation is needed.
- Visual Studio 2012
Here you install VS 2012 and all the related tools (Office Developer Tools for Visual Studio 2012 and the SharePoint Client Components) on your local machine and do the development without installing SharePoint 2013 locally.
But how about the traditional way of development? Where you had SharePoint and Visual Studio and tools, everything locally and do the deployment and testing without much fuss? Remember, setting up a SharePoint developer workstation?
Coding and life; what our kids are missing
Wandering around the land of Facebook, came across a video (watch it above) shared by a common friend. It got me thinking back in the time when I first got access to a PC (maybe way back in 1988 or 89) with a green screen and a blinking cursor announcing proudly the DOS prompt.
I just cannot forget the rush, the excitement of running first set of commands on DOS prompt and toying around with BASIC, DBase. Document editing with WordStar and WordPerfect. Playing around with DotMatrix printers and access to first Daisy Wheel Electronic Typewriter and excitement of connecting it to a computer and watching with wide wondering eyes, as each character printed itself (without touching the keys).
So what has learning to code to do with everyone’s life? Read the rest of this entry »
How to find all the websites using enterprise features in SharePoint
A customer came up and said, we are having a large number of SharePoint Enterprise licenses and we want to know how many websites in our Farm are actually using Enterprise features of SharePoint.
In SharePoint, enterprise features are available by enabling the SharePoint Feature called as “PremiumWeb” with featureID as “0806D127-06E6-447a-980E-2E90B03101B8”. A good list of available enterprise features and their contents is available at http://blogs.msdn.com/ekraus/archive/2008/08/13/enterprise-features-exposed.aspx.
Now to find out which websites are actually have the Enterprise features (using them or not, is a totally different area of discussion) enabled for them, we should be easily able to iterate through the webs and their sub-webs and then check the feature list of each SPWeb object and see if we have “PremiumWeb” feature available or not. If the feature exists, that particular web has got enterprise features enabled.
Below is the code that I used to create a sample console application, which would give us a count of SPWebs which have got “PremiumWeb” feature enabled.
namespace FindPremiumWebs { class Program { static long featureCounter = 0; static void Main(string[] args) { if (args.Length > 0) { Console.WriteLine("Checking webs under {0}...", args[0]); Console.WriteLine("Found {0} webs using Enterprise Features.",
getAllPremiumWebs(args[0])); } else { Console.WriteLine("URL not specified"); } } public static long getAllPremiumWebs(string siteURL) { using (SPSite site = new SPSite(siteURL)) { using (SPWeb web = site.RootWeb) { CheckSubWebs(web); } } return featureCounter; } private static void CheckSubWebs(SPWeb web) { foreach (SPWeb subWeb in web.Webs) { foreach (SPFeature feature in subWeb.Features) { if (feature.Definition.DisplayName == "PremiumWeb") { featureCounter++; } } CheckSubWebs(subWeb); subWeb.Dispose(); } } } }
This console application expects that a URL of the root site be passed to it and it will iterate all the sub-webs under that root site and give out a total count of webs using (oops! enabled with) enterprise features.
As always… Happy Coding
Control a Windows Service from SharePoint Central Admin site
You are a very good developer and have created a great windows service that works like a charm and your CEO likes the functionality and would love to have your SharePoint Administrator control it from the SharePoint Central Administration Site !!!!
What a lovely scenario 🙂
But what also is interesting in this is, that the usual way to control windows services will not work properly when used from within the SharePoint. So then how do you do it? Well, SharePoint itself comes to our rescue and provides us a couple of classes knows as SPWindowsService and SPServiceInstance which will allow you to control your windows service from SharePoint.
Well, there are a few steps that you need to follow to make sure you are able to control and use the windows service from within the SharePoint’s context.
- Use the classes SPWindowsService and SPServiceInstance classes to wrap the Windows Service.
- Add these services to the Services to the servers of the farm.
- Register the service to the desired servers in the farm.
- Provide custom aspx pages (as Application Pages) that can be used to start/stop the service.
- Use SPJobDefinition to start the service. This way, the service can also be started on a remote server.
For further reading, I would suggest that you go through this article in April 2009 edition of MSDN magazine.