Is there a Kentico Small Business Edition for purchase?
https://www.kentico.com/download-demo/free-cms-for-asp-net/kentico_12_editions.pdf
You should email sales#kentico.com and ask them. Since what is available to purchase starts at Base on their site, this small business one might be a free one under special conditions or no longer offered.
The Kentico Small Business License was introduced in 2009 as something that is only available to Kentico partners. This was following feedback from existing partners that smaller clients who did not need the full features of Kentico CMS.
It is still available as far as I am aware, but you would need to be a partner to get access to it.
Related
I am an experienced ASP.NET C# developer who is investigating using Sharepoint for document management for one of my clients. They want an intranet site with blogs and other stuff in addition but this will need to adhere to their brand guidelines.
Apart from the faff of setting up a working development environment to what extent do you get document management 'out of the box' with just using Windows Sharepoint Services? (the client understandably would rather not line Microsoft pockets further if possible)
Or put another way, how long would it take to add document management to an ASP.NET site?
Thanks
Oliver
WSS will give you all the document management capabilities that you need. If you pair it up with Search Server Express (which is also free), youget a complete solution for zero investment. We've even based a company portal of a major corporation on that. Doing it yourself in ASP.NET is a waste of time to say the least. The SharePoint platform gives you an enourmous value and the learning curve is actually not that tough
You definitely don't want to go and implement something like this yourself when a freely available (and powerful) solution like Windows SharePoint Services already exists. For most requirements I'd say the features in WSS are enough, but it really depends on what your client is looking for. For example you get:
Support for versions of documents
Exclusive check-out
Management of content types
Integration with Office applications
Meta-data
If you need to support records management scenarios, then you'd need features found in the SharePoint Server product. I'd start with WSS and see how far that gets you.
I would highly recommend looking at SharePoint Foundation 2010 over Windows SharePoint Services 3.0. It's the latest version of the basic SharePoint infrastructure (with the obligatory name change!).
SharePoint Foundation 2010 is a lot easier to work than WSS in terms of deployment, management and, especially, development. Plus there are new features in Foundation that you can start using.
Don't forget that SharePoint Designer 2010 is also free and is a great tool for customizing SharePoint.
Some links to get you going:
Download SharePoint Foundation 2010
Get Started Developing on SharePoint 2010
Let's assume that you've created a SharePoint solution - a WebPart, a feature for a List Template, whatever - that you are planning to sell as a product.
How would you go about handling licensing of your solution?
I'm looking for some input in at least the following areas:
Code-wise:
1.1. Where do you keep the license itself? as a file somewhere? (then what happens in farms?) as a property in the property bag of the farm?
1.2. Do you implement "home-calling" - where your solution validate the license every now and then against your company's servers?
1.3. Any other best practice in this area will be welcome...
Business wise: How do you license - per user? per server? per instance (in case of WebParts or List Templates)?
Thanks.
I could tell you what we do:
We have a separate farm solution that handles trial/registration support for all our products
The license is eventually stored in the farm property bag (you have to support multiple servers)
We have a page to enter license key under the central admin solution's page
We license by front-end, you can know the number of front-end in the farm in code.
All products have a product name and the license key is a one-way encryption containing the product name. the trial support solution handles key validation.
1.1 You have to put in in the documentation and in the distribution files.
1.2 I would not do that for a sharepoint web part.
1.3 Invest in layout, documentation, support... Not just in the product itself.
Nobody will be able to answer that without knowing detailed information about your product, your market, your competitors, the alternatives, etc. Consider this book if you are serious about pricing.
I want to use a CMS that can be accessed by my clients via the internet. All SharePoint usage I have seen is for intranet sites only. What I am looking to do:
Landing page for all clients, with general information.
Client login to client specific portal page with client specific information.
Accessible via the internet. The clients may or may not have SharePoint.
General and client specific wikis.
I won't be hosting this myself. I would be looking for a hosting provider as well.
I am also looking at using DotNetNuke, which has a lower cost of entry. I am open to suggestions of other CMSs, but my skills are built around C# and ASP.NET.
Before going down the SharePoint path, I wanted to make sure these things are possible.
Thanks!
Update:
Thanks to all that have given me some points to ponder. In summary, here is what I have decided to do (given my current skill set):
SharePoint can be used for my needs (my initial question). Many great example sites.
DotNetNuke as my CMS. I realize other good CMSs are available, but I prefer to stick to the Microsoft stack.
Branding will be easier in DotNetNuke.
The site will not be very big and not used by many. SharePoint will be overkill at this point.
Many of the 'modules' I am looking to use (wiki, forum, ...) seem to have more options/maturity using DotNetNuke.
Biggest Deciding Factor
Integrating a CMS solution with my software product and then installing/implementing this solution for individual clients will have a much larger cost with SharePoint. DotNetNuke will allow me to 'leave behind' the solution with the client without having them to invest heavily in SharePoint if they do not already own it.
Thanks to all!
Ed
Everything you require is supported by Windows SharePoint Services 3.0, which is included at no additional cost with a Windows Server license. However, SharePoint does have an administrative and development overhead that you could avoid using a different platform. It doesn't sound like you would really be leveraging any of SharePoint's particular strengths (document management, Office client integration, ad hoc collaboration sites, etc), so it's probably not worth the extra effort.
So in short, the answer to your question is "Yes", but it's probably not your best option with these specific requirements.
Check out the Top 17 case studies for Microsoft Office SharePoint Server 2007 and several new MOSS-based web sites. There are some nice Internet websites too.
there are heaps of SharePoint sites out there facing the internet. There’s a great list of over 1,000 of them on the WSS Demo site here: http://www.wssdemo.com/Pages/websites.aspx
All of the requirements you’ve listed are achievable with the externally facing SharePoint model. There’s an obvious cost impact of going down the SharePoint path versus DotNetNuke but it’s certainly achievable in terms of functionality.
Kentico offers SharePoint Connector which allows to publish SharePoint content to external sites: http://www.kentico.com/cms-asp-net-features/sharepoint.aspx
All the things you mentioned are possible. Note that hosting a SharePoint server can be expensive. Most hosting providers charge you a dedicated server hosting plan.
Also I'm not impressed with the default wiki solution in SharePoint. You might want to consider a 3th party wiki tool and point your SharePoint Search towards it so that the results are shown in your search results. Drawback is that you loose the security trimming.
You might also be interested in the BPOS solution. A (kind of) hosting service for SharePoint that Microsoft is offering.
I work for a large organization and we have been utilizing SharePoint for document library. Yesterday my boss called me to his office and asked me:
"I heard that SharePoint is an ECM! So what can it do for us?".
"What kind of problem do you want us to solve utilizing SharePoint?", I replied.
"I want to know what it means when they say it is a ECM and how it can help us?", He said.
I told him it has Document Management, WorkFlow, Records Management, Search and some other stuff.
Anywho, He wants me to put togetter a list of things that SharePoint offers as an ECM.
You might find some useful info on the MS ECM team's blog.
Microsoft Office Sharepoint Server has a substantial content management system available. What was previously Microsoft Content Management Server was discontinued and that functionality was put under the Sharepoint umbrella. Usually this is referring to web content, but it can honestly be any kind of content relevant to an enterprise. It is intended to be a direct competitor to all the major WCMS out there, focused especially on the enterprise (governance, auditing, security model, etc).
That having been said, the current iteration of MOSS's EWCM pretty much blows. If you can develop your CM strategy to be parallel to MOSS, it can work out OK, otherwise it's much more pain than it's worth. Use SP for document management and use something else for content management.
Sharepoint is a collaboration platform restricted to a windows environment
Give Alfresco communities (labs) a go is my opinion here as it 'acts' as a Sharepoint server so Microsoft Office suite will not notice the difference but your wallet will...
Er... think the boss got a bit too much $$$ to spend. But really, an't we supposed to deploy a technical solution to solve a business problem.
The list of features can be found at
http://sharepoint.microsoft.com/product/capabilities/Pages/default.aspx
I have been tasked with developing some large ERP applications (some legacy apps being rewritten and some new apps) in Sharepoint. As I've come up to speed in Sharepoint, I see the value and ease of creating team sites, and the examples I've found online and in books are all tailored to intranet department portals, or simple line-of-business apps for companies that don't have large legacy ERP systems. I have begun to believe that if one is going to create a large application that interfaces to several different legacy systems and spans several departments, that building custom webparts in Sharepoint just isn't the way to go.
Is Sharepoint a viable application framework for creating and hosting large ERP applications?
If so, can anyone please point me to references describing the architecture of such a system?
If not, can anyone please point me to references that I can cite as arguments for not using it?
As someone who has spent the last 15 years writing ERP applications I would say Sharepoint would be an extremely bad choice upon which to build an ERP product.
The Sharepoint table structures would be very ineffective for producing reports.
There is very limited capability for validating data.
There is no native support that I am aware of for maintaining the integrity of relation ships between documents.
Sharepoint works well as a portal into existing LOB applications, not as a platform to build a data-rich application on top of.
I'm currently deploying a ERP system written in Sharepoint for a client. I've been working on this for about a year now and from what I've seen, Sharepoint introduced as many obstacles as it made things more complicated.
Things made simpler:
Credentials automatically synced to AD.
Document handling and versioning out of the box.
Great Office integration.
Things that sucked:
You need to learn the Sharepoint way of doing things.
You have another dependency in your ERP.
It's pretty clunky.
I would recommend reading Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs before making a decision
I use SharePoint 2007 (MOSS) at work as part of a larger ERP installation. We heavily use the Business Data Catalog to interface with external systems and make their data visible and searchable within our MOSS portal.
In our architecture, CRUD operations on the ERP data are handled in our ERP line of business systems. MOSS and the BDC then pull the data out of the ERP database and display it as datagrids embedded in various portal pages. For example, the HR site has a MOSS page for tracking the current status of pending performance reports.
Another compelling feature of MOSS and the BDC is the ability to expose BDC datasources to the MOSS search service. For example, when a user searches for John Smith using MOSS search, the public ERP record for John Smith is inlined with the search results. Clicking on the link in the search results redirects the user to the right page in our ERP system, rather than taking them to a MOSS page.
We don't use MOSS exclusively as an ERP system, but we do use it as a presentation and reporting layer on top of our ERP system.
The MS Dynamics AX system utilizes Sharepoint extensively, in fact there are tool kits that allow users to build web parts and so forth that extract data directly out of the base AX objects. Here is a link that talks a little about the Sharepoint integration AX+SP. Currently there is still a significant portion of AX that does not reside within Sharepoint, but their direction appears to Sharepoint enable a significant portion of the application. I do not think that an entire ERP system could reside within the Sharepoint infrastructure, but from an MVC perspective it could certainly become your View infrastructure. It appears to me that this is the very direction MS is heading, but I'm just making hypothesis on their future plans.
Building custom webparts in SharePoint would not be the way to go for complex legacy systems.
SharePoint would still give you a lot of mileage if you created a custom navigation provider for the main navigation (based on an xml file for example). This would allow custom asp.net pages to display "like" they were still part of SharePoint, giving the illusion of one all encompassing app.
I think the only reason people want one huge application has more to do with Information Architecture, look and feel and findability than any technical architecture reasons.
A solution that creates separate websites for appropriate applications that are still skinned and linked into the SharePoint information architecture and still searchable from the main interface could solve the "need" for the "Enterprise" part of ERP, while still creating appropriate solutions for what are really separate applications.
The mental model I use is not so much building the apps "in" SharePoint, but creating a 'window" in SharePoint to expose the app.