We have an existing issue with the Audit Setting on individual entities. When a managed solution is deployed from Dev environment to another, the 'Enable Audit' setting is turned off after the deployment (while the imported CRM soultion has the Enable Audit turned on for the corresponding entity). This only happens for a few entities.
Does anyone have any idea why this might occur ? and is there a way to fix this ? Please assist.
Thanks
Rajesh
This is one of the managed solution "gotchas" in crm 2011. Importing a managed solution that contains those entities will effectively turn off Auditing.
For verification, more info take a look here: http://blog.sonomapartners.com/2011/09/some-assembly-required-unmanaged-solution-gotchas.html
Quote: "What we found is that the Enable Auditing in the following areas checkboxes are transferred from one environment to another, without needing to select any of the system settings for export. However, the Start Auditing is not. When documenting the steps to perform a deployment, make sure that manually checking this important box if you are performing auditing on any of your entities is one of those steps."
So you will have to make sure start auditing is enabled on these entities manually. I assume you would be able to automate "start auditing" using a C# Console App as well if automation is an important part of your deployment process.
So, to clarify, when exporting the managed solution, it seems like the following line is transferred:
Here's a work around for this problem that I found here:
Simply open up the managed solution zip and edit the setting for IsAuditEnabled to read 1. After that zip up the solution again and import at will.
A bit of manual work but it should work. Also, make sure going forward you remember to do this. If Auditing is turned off you will lose all Audit Data for the entity...
Related
Before: We had (still working) a couple of CRM 4.0 servers working: A productive one and a test one. We would perform any changes on the test server first and, after testing, replicate them in the productive server. For entities (custom or not) this would mean using the "Export Customizations"/"Import Customizations" functionalities. Pretty straight-forward stuff.
Now: we're testing CRM 2013 and trying to do the same with a couple of servers. We set up our data structure by hand (took some time) including the creation of all our custom entities, which are not few in number.
My question then is: How can I perform a bulk entity export-import in the same manner as it was with 4.0? I've tried selecting saving the entities to a Solution package, export the package from one server and import it onto the other. System entities feature in the target-server's import list but not the custom entities! And they are a part of the original solution packet (both checking it through CRM itself or the package file's XML code directly)
The lack of online help on this may imply that I'm not approaching this in the right way and I presume this is something already standard in CRM 2011.
Can someone give me a hint?
Thanks in advance!
Ok, I have no time to delve into reasons and explanations but things got solved.
I tried to export ONLY the custom entities and their related entities and it ended up working out.
Afterwards, trying again to export ALL entities ended up working just fine!
Therefore, i'm still not fully convinced I was not doing anything wrong. Most likely I just missed some essential basic small step or detail no one thought of due to it's "self-evident" nature.
(I guess being too stuck to CRM 4.0's "modus operandi" takes it's toll when updating...)
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.
Assuming I received a managed solution from another developer which contains an amended contact entity. How should I best make changes to that entity without affecting theirs'?
The changes would be additions as opposed removing anything they have done but ultimately for the end user I want them to see a mix of their original contact entity plus my changes. Is it best I simply create a new unmanaged solution, add their existing contact entity and make changes that way? Or do I start afresh adding in the contact entity from the system layer.
If you are working with these solutions internally in your organization you should almost always use an unmanaged solution. Managed solutions are for the most part a way to box your CRM customizations in order to sell them and protect them from being changed. If this is the case you are dealing with you can probably still amend the entity but you would have to do it in the default solution or another solution - sounds like you are already going down this track. I haven't tested importing a managed solution and changing an entity customization but this is how I would expect it to work.
Yes, the best option is to create managed solutions will which will not override the existing customizations but it will add any extra customization without affecting the existing ones.
You should use managed solutions only when you want to have the feature to install or an uninstall changed you have imported.
Only if the 'Customization' field for the amended contact entity is set to true, you can directly modify the update and include your changes there. Otherwise, you can create your own managed solution that has the contact entity modifications and import it to your system. Dynamics CRM will then merge your changes with the other ones.
I have a case where if a SharePoint site owner decides to break permissions inheritance and directly manage site membership, I'd also like to correspondingly modify view permissions on items in a specific list in the top-level site.
How can I best catch those changes so I know when to apply the appropriate changes to the list items?
I'd like to have some C# code be notified when a site's permissions are changed so I can programmatically modify the appropriate list item permissions.
The best way to do this (unfortunately) is to periodically query all of the sites and check to see if inheritance is disabled. I had a similar problem and used powershell scripting to create a report on site security. If you haven't used Powershell before, don't be intimidated. The syntax is VERY similar to C#.
You can use SharePoint auditing to monitor permission changes. It will track changes down to item level. The downside is that you have to turn this feature on and it will hurt performance somewhat.
As for notification, I don't think auditing tells you about changes. I'm pretty sure you would need to poll the audit log.
There's heaps of information about auditing in this article on MSDN.
Another approach which I think might do a very good job of this is to use the SharePoint ChangeLog. Bascially, this is used by SharePoint during indexing, with the log telling the gatherer exactly what has changed, and what should be indexed during an incremental crawl.
When you have a permission change, then this should be picked up during an incremental crawl. The ChangeLog has specific parameters that can be passed to identify changes to permissions. Take a look here at the SPChangeQuery Class:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangequery.aspx
Specifically you can look for ChangeTypes:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangetype.aspx
Including:
AssignmentAdd
AssignmentDelete
MemberAdd
MemberDelete
...and more
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.