Make sure you have a logo, screenshots and some descriptive text ready for the app submission. A version of your .app file that has been compiled for Release.
Decided how you are going to licence your app. The app store itself allows you to define how the app will be licensed, will it be free, will it be per purchase, per user, will there be a trial etc. Some of these decisions are not simple and require significant forethought and in some cases additional development work. For our app I decided to keep it simple and go for a free version. Microsoft published a couple of great blogs / articles helping with the licencing over at the Office apps blog.
Finally, make sure you have tested, tested and tested your app again, the submission process is very thorough and tests the functionality of your app across not only IE but all supported SharePoint 2013 browsers.
Once all of the above is ready, submitting your app is relatively simple. Navigate to the Seller Dashboard and follow the prompts to submit the app.
First choose a listing type, our app is for Project Server, so we need to choose an app for SharePoint, then click on next.
In the next screen you will be asked some information about your app like the name, version, category to list it under and some other bits and pieces. The most important part are the testing notes, these are your only real way of passing information through to the testers who are looking at your app.
As we are making the app available to everyone, there is no need to choose Trial support. Click on Next. The final bits to add before you can submit the app are screenshots and some descriptive text and links to support, EULA and Privacy policies.
Once you’ve added that text, click on Next and your ready to submit for validation. From experience, the validation process can take around 3-5 working days. Unfortunately at the moment there is no progress indicator of where you are in the process, with the app either being in a Draft or Approved state. Once the app has become approved, it takes a few hours for it to propagate down into the SharePoint app store and to become available for everyone to download and start using.
The following SharePoint Server 2013 installation scenarios are not supported:
You try to install SharePoint Server 2013 on a drive that is formatted by using Resilient File System (ReFS). In this scenario, the installation fails, and the following error message is logged in the Setup log file:
var>datetime:: Catalyst file system check failed: The path root D:\ is not NTFS datetime:: Showing message Title: ‘Setup Warning’, Message: ‘The install location must be on a drive formatted with NTFS. Select another drive.’ datetime:: Message returned: 1
You install SharePoint Server 2013 in a workgroup.
You install SharePoint Server 2013 on a domain controller. This scenario is supported only for development configurations and not for production configurations.
You install SharePoint Server 2013 on Windows Web Server.
You install SharePoint Server 2013 on a virtual machine (VM) that uses Dynamic Memory. For more information about best practice configurations for SharePoint Server 2013 and virtual machines, go to the following Microsoft TechNet website:
In this post, we will discuss about the steps to fix the following Workflow error – ‘Unable to load workflow actions from the server. Please contact your server administrator’
When needed to make some modifications to one of my sites with custom SharePoint designer workflows. I open SharePoint Designer, click Workflows, click my workflow and I get Message box that
Unable to load workflow actions from the server
Turn on Failed Request Tracing on IIS â this did not show any more specific error, only 500 Internal Server Error on SharePoint web service call
Checking ULS, nothing logged there
Created empty site collection with Publishing feature and workflow â workflows open correctly
Same site restored to another server â workflows open correctly
We do not support custom developed Workflow actions in our sandbox!
Compared farm solution on one server and another server. I see some differences in solutions. I think, can have something to do with installed solutions. There is one suspicious looking solution there that we once tried to use to move site with workflows and forms from one farm to another (by saving site as WSP package). It is installed globally. I know we abandoned idea as it fad site backup/restore instead. I retract this solution. I go back to designer and find workflow working.
Custom solutions is another checkpoint in investigation of this nasty error. I have read tones of msdn threads on this one, and causes can be different, but Designer will always give you same error message. My solution was generated from saving site as template (WSP package). It was site with custom workflows and some infoPath forms deployed to this site as content type.