I would like to know the creation date and time of all Web Applications in a SharePoint farm. But after studying the SDK and inspecting SPWebApplication objects with SharePoint Manager it looks like this information is not available! Can you confirm this or do you know a way of obtaining these metadata?
I'm not aware of such a property for a web application. Two alternatives come to mind:
Look at the Created property on the root SPSite's RootWeb, or even look for the earliest date across all site collections' subwebs. Not exceedingly reliable.
Use IisSettings to check the creation date of the IIS sites' folders on the file system. It seems to me this should be pretty reliable as long as the server was part of the farm when the web app was created.
Related
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
I've built a SharePoint user control (not a web part) and am deploying it via Solutions, Features, etc.
It's a commercial component and I want to be able to store license information once it's registered. I've got all the licensing stuff down and working, however, I am trying to find a "global" (i.e. farm level) place to store the information (so it works on multi-server farms).
This is intended to be a commercial component so I have no control over security policies, application pool accounts, etc. I need it to work without admins needing to reconfigure their farms.
I've considered:
Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.
Hierarchical Object Store - Several security gotchas - Namely app pool needs access to Config database (which many environments won't allow)
Root site property bag - Possible. I can update all the Root Sites Properties at the time of registration, but what happens when new web apps are created? User has to register component for each web app?
Registry, file system - Not persisted across servers
Custom DB - Seems like a lot of places for this to fail.
I know other commercial vendors are doing it somehow.
Any ideas?
Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.
There are many many different opinions about putting your configuration stuff in web.config. Personally, i would NOT recommend it, because SharePoint is automatically pushing changes to it and you can't really control what's going on.
I've had similar requirements, but at a SiteCollection level. What i did was creating a simple custom list with 2 columns (Key, Value) at the root of my SiteCollection. Within my code, i hardcoded the name of the list and used elevated privileges (because i set the list permissions to admin-only) to access the values i needed.
You could basically do the same, but not at the root of the SiteCollection level, but in the Central Administration. This way, you can access the configuration list from anywhere within SharePoint.
Another idea would be setting up a simple configuration database and then use a custom web-service (which is deployed within SharePoint) to get it's values. However this adds quite a lot of overhead to such a "simple" task and will get you in a lot of trouble without proper exception handling/logging.
We use SharePoint 2007 and have set up a web application with several site collections. One for each of our clients. We'd like to synchronize content in all of the site collections. Maybe having a central repository, then all other site collections get content from here.
I was looking at Lightning Tools Conductor web part and seems a pretty good solution. However, I'm wondering if this can also be possible using the Content Deployment feature to copy a site from the central repository to all other site collections.
I do not advice you to copy and thus duplicate the information from your central repository to the other site collections. You'll lose precious disk space, performance and scalability.
If you have content that is created in a common site collection, you should either use the built-in web services or create dedicated ones to retrieve the content within the targeted site collections.
I usually create cross site collection look-up fields that allows a contributor to pick an entity from my central repository in a visual way and apply the rendering of the content once the page is in view mode.
That might not suit every need but I don't think content duplication is a wiser choice.
Edit : re-reading your question, is there a specific reason why you want to copy a complete site (spweb I guess) rather than specific content inside ?
I have a piece of data, a simple string containing the server name that the SharePoint solution is deployed to, that I retrieve from a configuration store in a helper method in a common DLL used throughout my solution. This helper method is used throughout my custom pages and web parts, to build a number of URLs, etc.
I would like to persist this string, and prevent it being repeatedly retrieved from the configuration store. My Sharepoint installation is currently on a single server, but will be migrated to a SharePoint server farm in the near future, so simply determining the server name of the current request, etc isn't an option. I have looked at caching as described in the best practices for SharePoint, but unless I use a coherent cache like NCache or Velocity/AppFrabric, I will again have issues when the move to server farm occurs. Given that this is a single string, adding a full caching solution such as Velocity seems like overkill.
Does anyone have any suggestions on the best way to persist this data? Am I missing something obvious here?
Thanks, MagicAndi
Look into using the Property bag that is exposed by all major SharePoint objects to persist information. i.e.
SPFarm.Properties
SPWebApplication.Properties
SPSite.Properties
You could:
Store the string in web.config. You can programatically change the web.config on all the farm's webservers using a SPWebConfigModification
Store the string in a SharePoint list and read from it. I usually use this solution because I have more to store than a single string. The list is 'available' on all web servers and I cache its values in an ASP.NET cache object. Someone made this concept into a solution you can download and install: SPConfigStore
This article may be of use to those looking at storing configuration data in SharePoint:
Six ways to store settings in SharePoint
You can use SPPersisted to do such kind of operations.
I want to add some OSIsoft RtWebParts to a Sharepoint page. I want these trends to be shown in different timezones for different users. What I'm finding is that they are always shown in EDT.
Ideally, I want a solution for configuring the presented timezone by page or by user.
Michael,
I am the product manager at OSIsoft for RtWebParts.
The time zone is controlled by the SharePoint site, not the web server. One possible workaround it to create a SP site for each time zone that you would like to support. Unfortunately, you would then face the challenge of maintaining the content for multiple sites.
I would also like to make a correction to the workaround that is described above. The workaround should use the RtActiveView web part(which uses ProcessBook .pdi files), not RtGraphic (which uses ProcessBook .svg files).
Thanks,
Tamara
The official response from OSIsoft is: this cannot be done.
RtWebparts objects always use the timezone of the Sharepoint site hosting them. Period.
Other than spinning up a new sharepoint site for each timezone you care about, there is one unappealing workaround:
Create your display in ProcessBook wherein you configure the time offset as desired
Include the ProcessBook PDI file within an RtActiveView web part
Repeat for each timezone
You're still stuck with one timezone (set in the SVG) but now at least you can get multiple timezones without multiple servers.