We recently migrated a bunch of document updates up from a pre-production server to our production server. We'd attempted to use content staging, which had worked mostly OK in the past, but this time it failed with a lot of parent records not found errors. Our outsourced developer used the Documents tab of the Staging module to sync subtrees across. However a few files got missed, or didn't work correctly the first time. So I'm trying to move them now, and I'm running into a problem.
After expanding the content tree and clicking on the document in the Documents tab, and selecting the correct target server (we've got bi-directional staging set up), we're getting an error: Dependent task 'Move document See Things Differently' failed:Synchronization server error: Exception occurred: SyncHelper.ServerError: Document node not found, please synchronize the document node first.
Looking at the tasks listed, I don't even see a Move document task anywhere queued up for the target server.
Is there any way I can move this document up to our production instance? I've looked at the site export as an alternative, but it doesn't look like I can export just this one page. Am I going to have to recreate the page on Production instead?
The best way is to attempt this sync is to clear out all the staging tasks and do a full sync from the root of the website. Most likely what happened to some of the documents which are stating "moved..." is the pages were reordered. Which means every document below that document's parent will be updated on that level. So simply moving or reordering one document out of 10, will trigger 10 staging tasks. If you don't sync those to the production site, the order will be off according to the staging site.
I have had a problems similar to this before.
This typically works:
Create a copy of the document, put it in the same location in the
content tree.
Delete the original document.
Make any changes to the new document name, URL, aliases, etc (remove the '1' for example)
Then push that new document with Kentico Staging.
Its a bit of a hack but sometimes necessary.
Brenden is right on target about clearing the staging tasks listed under "All tasks" before you try syncing again. We've run into these errors on our sites when we've tried pushing a large number of docs from staging to production. What worked for us was deleting all pending and failed "Pages" tasks, then under the content tree in "Pages," navigating to the first child level and syncing "Current page" all the way to the closest parent directory, and then syncing "Current subtree."
For instance, if the problem doc is in, say, the "18" dir, select Articles and sync current page, then 2016, then 01, and for 18 sync current subtree.
content tree syncing screenshot
The best way is to use Kentico in-built Staging module and use that to first move objects and then the pages.
I have never faced any problem moving a large number of nodes(around 8000). That's the best possible approach.
In case your website a large no of custom table items let's say 50K, then I would do an export/import of the table. Synching so many entries usually has given Connection Time Out error before.
Thanks,
Chetan
Related
This wiki (https://www-10.lotus.com/ldd/ddwiki.nsf/dx/Headless_Designer_Wiki) seemed to indicate that you can only create NSF under your Notes Data directory. I have done a couple of quick test and the only workaround I can find is to install Domino Designer on the same server as the target Domino server and set the target as the Domino data folder (i.e: C:\Domino\Data\sample.nsf instead of just sample.nsf).
The reason for this is I am trying to find an automated way of the following operation
Import ODP into workspace
Associate with a new NSF, but choose a Domino Server as a target
Does anyone have other workaround for this ?
I wish I had a more complete answer for you, but as this is still unanswered after a few days, I'll try to add some insight. It sounds like you have some experience getting headless DDE builds to work, so I won't focus on that. If you're looking for my take on headless DDE builds, I blogged on the subject a while ago, but since adapted the Jenkins CI based process I outlined there for a GitLab CI runner based solution, which I described in another SO answer.
Firstly, I would strongly recommend against setting your Designer target as the same as a server instance. This might work, but seems an unnecessary complication, and potentially issue prone, IMO.
My interpretation of your steps:
automatically receive updates (e.g.- on master branch, or all commits, etc.)
perform build via headless DDE
deploy built NSF
Splitting apart the logic for deploying of the built NSF is ideal here, since you have an asset that needs to be parked in a server path. The two main approaches I see are either:
having a dev/staging server that you can programmatically restart on demand
a more complex mechanism, in an NSF or server plugin, that will ingest the NSF's design and replace the design elements in a (newly created) destination NSF
As you can imagine, that last one is a bit tricky, but it was something I've left off working on, until I have more "free time". As for the former, you'll likely want someone with a bit of admin/operations skills set assist you, but in my mind there would be a total of three scripts involved:
one to down the destination server (this is why it should be a dev/staging server)
one to copy the built NSF to the destination file system path
one to start up the destination server
If you have a design task set to run at a certain interval and point the staging server for any changes, you could conceivable pull from that at whatever your interval is; nightly, etc. I hope the perspective helps.
I have a local replica. From domino designer, when I open any design element, I get this error "Invalid or nonexistent document".
But this error didn't occur on server copy. Now you can ask you don't you work directly on server copy. the point is, it's very large db and have serveral xpages and custom control, etc.,. so building the db on remote server copy is painful for me. so work on local copy, save, build, and replicate to server copy.
what I have tried so far.
deleted local replica and created new replica. still error
replaced with my latest template. still error
felt some design elements have corrupted. so replaced both server & local replica with blank template to remove all design elements. and again replaced with latest app template. still error.
ran load fixup on server copy and replicated in local. still error
do anybody have a clue on this issue or any workaround to resolve this?
Thanks in advance for your help.
This may sound strange but I have solved weird things before doing this.
Close Notes and designer. Load Task Manager and make sure all Notes Tasks are ended.
Try to following:
from the notesprogram folder run ncompact -c path\dbname
delete \notesprogram\data\Cache.ndk
delete \notesprogram\data\log.nsf
rename \notesprogram\data\workspace folder to workspace.sav
rename desktop8.ndk *.sav
rename bookmarks.nsf *.sav
Launch notes and designer then test. If it works then great. If not rename everything back. Note, renaming the above will lose your preferences etc.
My dev server seems fine, i can access all the sub levels with the form (Recorded Data, General, etc.). My staging site only has Alternative Forms and Versions.
I thought something may have gone wrong with the migration and manual sync tasks, but I attempted to create a new form in staging, the result is the same.
I went back to the documentation to see if I missed a step when I attempted to create a new form, but nothing is mentioned. Is there a site or setting flag i missed?
There could be a multitude of issues which are causing this but first things I'd check are:
Check your Kentico event log for errors/warnings
Check the server event log for errors/warnings
Ensure all your files are copied from dev to staging server(s)
When you moved from dev to staging, did you resign your macros?
Did you clear your cache on the staging server and in your browser(s)
I'm guessing it is an issue with cache but the others should also be reviewed, especially resigning the macros.
I am deploying a SharePoint 2010 web part that uses the microsoft .net charting tool to build charts. I need the chart handler added to the sharepoint web.configs automatically. I've been told that when you create the wsp the package can be told that when the program is installed it needs to modify the web.config to add these handlers.
I have seen a couple options out there:
-WebConfigModifications
-Safe controls
I don't know which, if any, that I should be using. I don't know for sure if this will be a first time installation for the application (we're moving sharepoint environments at the same time we are updating this. I think that it will be a first time installation on that new environment but can't be sure.)
And I definitely do not know how to implement this correctly. I would appreciate any advice.
Also it may be important to know that I do not have any privileges on the server. I can't even deploy myself.
For example, this seems like good info: http://platinumdogs.me/2009/07/08/using-the-mschart-controls-in-sharepoint-moss-2007/ Except that I can't just write to the webconfig and restart IIS. It has to be automated and not a direct edit to the file.
Thanks all!
I would recommend that you use a Feature Receiver attached to your WSP to create the appropriate SPWebConfigModification entries when your solution's features are activated. Likewise, the SPWebConfigModification entries should be removed when your solution's features are deactivated.
Step 1: Create a Feature Receiver
MSDN has an overview of how to add a Feature Receiver: http://msdn.microsoft.com/en-us/library/ee231604.aspx
Note you'll want to handle both the FeatureActivated and FeatureDeactivating events.
Step 2: Use Feature Receiver events to add or remove SPWebConfigModifications
In those two events, you'll need to programmatically add or remove one or more SPWebConfigModification entries. These affect SharePoint's web.config file, but unlike a manual edit of the config file, they are stored in SharePoint's content database. This means that if the web.config is reset for any reason (and it happens), SharePoint can and will reapply the modifications, thus preserving your changes.
MSDN has an overview of programmatically creating and removing SPWebConfigModifications: http://msdn.microsoft.com/en-us/library/office/bb861909(v=office.14).aspx
It is very important that the FeatureDeactivating event properly clean up all modifications made during FeatureActivated, or you will end up with a proliferation of duplicate config entries. This means you need to really understand how to use the Path and Name properties of the SPWebConfigModification.
This article gives a good overview of how Path and Name are combined to create an XPath expression pointing to the node to be added or removed: http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/
Step 3: Test, test, TEST!
Lastly, test activating and deactivating your solution's feature in your local development environment to make sure everything is working properly. Note that the modifications will be applied via a timer job, so you may need to wait a minute or two to see the changes show up. Be sure the feature deactivation cleans up your modifications! (If you get into a mess in your development environment with duplicate modifications, you can always wipe the slate clean with a little PowerShell action.)
I'm wondering if someone can enlighted me a little bit on the Xpages build process and how this works with other replica copies of a database. Much of the advice I've seen posted regarding working with the the Domino Designer indicates (logically), that you'll have much faster response working on local copies and then replicating those to the server.
I'll usually save my changes locally, build manually, and replicate to the server, and most of the time, that seems to work fine. However, on some occasions, I've found that when I view the work I've done in the browser on the server copy, it hasn't seemed to update... in fact in a couple of scary incidents, it displays a version from several weeks ago (where is it even getting that from??). This isn't a browser caching issue, and I've opened the design elements (xpages, custom controls) on the server copy and verified that the changes ARE there. I end up having to perform a Clean on the server copy (not just a build) of the application, and then it displays as expected.
This seems like a foolish question, but you shouldn't have to perform a build on each replica copy correct? Any thoughts as to what might be an issue here? There is another developer involved, and he works directly on the server as he's in the same location, but we are rarely working at the same time, and never on the same elements. We are not using source control at this time.
We have seen similar behavior ourselves.
In our case, we do development on a server, clean / build project and then copy that database as a template to a deployment server. From there, we update design in the production database.
We have noticed that build process sometimes fails, especially when working over slower links. So we always repeat clean / build / refresh process a couple of times and we try to do it while in office with fast connection between the work stations and the server.
We haven't experienced build problems lately, so this repeating of build process obviously helps.
We have also seen that replicating design between local and server copies sometimes causes build related problems, which could explain the problems you are seeing. We have stopped using replication because of that and are now always working on the server copy directly.
I don't think that your not-using of source control software has anything to do with it.
I usually do all changes inside local template, then perform "Project \ Clean", then update design in server database. It works in 99% of cases. If not, I perform "Project \ Clean" once again. I hate this, but looks like it's the only way to get consistent code on production.