There is an issue with my Sandbox after it was refreshed from Production. All solutions are successfully copied over. However, fields that had Field Level Security do not show up under Field Permissions even though they have Field Level Security Enabled.
I can add and remove Field Level Security on fields that previously did not have it but am unable to do so with fields that previously had Field Level Security. The error I get, even as a System Administrator (same as in our Production environment), states that I do not have permission to modify those fields.
Next, I was able to add the Field Permissions in Test for the entity fields I wasn't able to previously by adding a Field Security Profile in Production containing the fields. I had hoped that I'd also be able to bring over which users were members after importing the Solution. Unfortunately, they weren’t and when I tried to add them again in Test, I got
Unhandled Exception: System.ServiceModel.FaultException`1 [[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Caller [MY GUID] doesn't have privilege for attribute [ATTRIBUTE WITH THE FIELD LEVEL SECURITY] of entity [ENTITY WITH THE ATTRIBUTE]Detail:
<OrganizationServiceFault xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/xrm/2011/Contracts">
<ErrorCode>-2147220906</ErrorCode>
<ErrorDetails xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
<Message>Caller [MY GUID] doesn't have privilege for attribute [ATTRIBUTE WITH THE FIELD LEVEL SECURITY] of entity [ENTITY WITH THE ATTRIBUTE]</Message>
<Timestamp>2014-07-30T16:55:44.9611645Z</Timestamp>
<InnerFault i:nil="true" />
<TraceText i:nil="true" />
</OrganizationServiceFault>
The added Fields are still not visible under System Administrator. Even removing the fields and then trying to add myself as a member still gives me this error. Looking at the XML, even though I removed field level security from the fields (confirmed they did not show in the Field Permissions list), they are not actually removed. I compared it with the XML I saw previously which had no field level security on any fields (this was before I tried making any changes)
Is this a bug? Is there a possible step that was missed?
I've seen others with similar issues, but they were for 2011 and the suggested answers of publishing twice didn't help.
tldr; Field Level Security issues when refreshing Sandbox from Production. Cannot disable and re-enable Field Level Security on fields that had Field Level Security enabled in Production.
This issue was resolved after CRM Support fixed this. It was an unintended bug on their end.
This issue doesn't exist for CRM 2015
Related
In IAM I tried creating the following policy for a user (account id in arn obfuscated):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-west-2:999999999999:table/busUsers"
}
]
}
However, it resulted in:
This policy defines some actions, resources, or conditions that do not provide permissions. To grant access, policies must have an action that has an applicable resource or condition. For details, choose Show remaining Learn more
Show remaining shows:
One or more actions do not have an applicable resource.
I looked up the Learn more link and it says to replace the arn in the Resource element with *. I am confused now. What does * mean? I want to grant access to a specific DynamoDB table of mine. How do I specify that?
EDIT: I removed all DyanamoDB actions and just selected one GetItem and it's:
When I deselect GetItem, both error messages go away.
When I select table Any, the first error message goes away.
When I select Resource Any, the second error message goes away.
Its because you are granting permissions for all dynamodb actions to a table resource, but not all of those actions are actually applicable to a table.
For example dynamodb:DescribeStream is not applicable to a table, only to a Stream, but your are granting permission to this resource anyway.
You can safely ignore this warning.
EDIT: You may not have realised you can just click Save Policy and it will work fine.
EDIT: Thanks for posting your screenshot. There are no errors here, just warnings, which might be better called tips in this case.
When you enter the ARN of a resource manually, AWS does not appear to recognise what type of resource it is (i.e. a table). If you add the resource through the table ARN generator, you wont any warnings. In either case you end up with the same policy.
It is possible that you are running into a bug [discussed by Amazon employee rob#AWS] of the IAM Policy Visual editor itself (and therefore not experiencing any actual problem):
https://forums.aws.amazon.com/thread.jspa?threadID=282453
When I alleviated my personal problem (which had me looking at this Question in the first place), my similar warnings still persisted (even after my problem was solved by something else) - that leads me to believe my similar experience per the Visual editor may have indeed been that bug (and not causing/involved in my prior problem at all).
We have clickdimensions installed in a 2015 CRM version. This environment previously used Exact Target for email marketing automation. We removed Exact Target before upgrading from 2011 -> 2013 -> 2015.
Whenever any user attempts to associate an email send to a marketing list, they get the following error:
The Relationship with Name = 'cdi_emailsend_list' was not found in the MetadataCache
The interesting part is that the relationship does exist. In the entity section of 'Customizations', an N:N relationship exists between the two entities and is present on both the 'Email Send' and 'Marketing List' screen. In the CRM database, we've also been able to find the relationship and the intersect table. All fields appear correct when we compare them to another entity having an N:N relationship with Marketing Lists.
From the traces of the error, we get more detail:
Stack Trace Info: [RelationshipMetadataNotFoundException: The Relationship with Name = 'cdi_emailsend_list' was not found in the MetadataCache]
at Microsoft.Crm.Metadata.ServerDynamicMetadataCache.GetRelationship(String name)
at Microsoft.Crm.Core.Application.WebServices.AssociateRecords.AssociateOneToMany(Int32 childType, Guid childId, Int32 parentType, Guid parentId, String relationshipName)
This would seem to indicate that CRM is looking for a one to many relationship rather than a N:N relationship.
We've tried removing and reinstalling the solution. That didn't have an effect on the error.
We've also spun up other CRM environments (2015 online and on-prem) and imported the Clickdimensions solutions into those environments. Those environments have no issue associating email sends to marketing lists. So, we've narrowed it down to an environment-specific issue.
Does anyone have any recommendations for next steps or what might be causing this issue?
My strong suggestion - get in touch with ClickDimensions support to clarify what's happening.
I have "You do not have sufficient permissions to access this page." issue when trying to access Wordpress wp-admin login as an administrator. The login page appears, but when the user details are entered the "You do not have sufficient permissions to access this page." appears.
The strange part is that I have another administrator account that accesses with no error.
I tried to create a new administrator account, but that also cannot access giving the above error message.
I have looked into the database and the users that don't work have wp_capabilities of a:1:{s:13:"administrator";b:1;}
The user that does work has: a:2:{s:13:"administrator";b:1;s:13:"bbp_keymaster";b:1;}
I am also running S2 Member plugin.
The only difference I can see between the account is this beginning section of a:1 and a:2. All of the sites I see say the account should be a:1
I don't think it is a plugin issue, as I assume then I would not be able to access either. I think perhaps something to do with s" Member plugin, but I'm now at a bi of a loss.
All plugins are updated and running Wordpress 4.0 (however this was an issue even before upgrade to 4.0)
All help gratefully received!
The only difference I can see between the account is this beginning section of a:1 and a:2.
Look more carefully. The working example has a whole extra section: s:13:"bbp_keymaster";b:1;
To understand why that matters, it helps to know that that is the format produced by by PHP's serialize() function.
If you unserialize each of those strings, you will find that the first is an array with 1 entry (hence a:1), with the key 'administrator' and a value of true. The longer string is an array with that entry plus another one, with the key 'bbp_keymaster', also set to true.
From this, it's easy to surmise that 'administrator' and 'bbp_keymaster' are the internal names for permissions which can be granted to a user, and the page in question is only available to users with the 'bbp_keymaster' permission.
I have 2 databases in one server, a Web App db containing XPages only, and another database containing documents. When I tried to open a document in Xpage, an error appears saying that I don't have access to the document (I did a checking using db.queryAccess(myUserName) and found out that I don't have access to the document database, even though my user name is specified directly as Manager). I created a new copy of the document database, then points my web app db to that. Here I have access to the documents! I had implemented this before and this is the first time I had this problem. What are the probable problem(s) with my original document database? I already did a fixup and compacting, but to no avail. Please help me... Thanks!
Please check the the "Maximum Internet name and password" option in the ACL settings. This option overrides every ACL entry: If you are Manager but the option is set to "No Access" - you have no access.
This probably isnt an issue with SiteCore per se but I've included it for completeness. I have sitecore 6.3 running under IIS7 using a custom identity for the app pool. I cant get Sitecore to write its logging information (using the default log4net settings) to the eventlog. I've followed the advice here: http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? and although it works fine when I make the custom identity a member of the administrator's group I need to find a way to get it working in production without such a security hack.
The weird thing is that I have a MSI that installs it (running under an account which IS a member of the administrator's group) and creates the correct registry keys in the eventlog for me and yet despite that, I am still getting the following error when I run the application using the custom identity (without it being a member of administrators).
log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of type [log4net.Appender.EventLogAppender]. Reported error follows.
System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
at System.Diagnostics.EventLog.DeleteEventSource(String source, String machineName)
at log4net.Appender.EventLogAppender.ActivateOptions()
at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
The Zone of the assembly that failed was:
MyComputer
log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found.
Thinking I could narrow it down to a registry permission issue I granted Everyone full permissions to the following registry key and subkeys but it didnt work either: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
The custom identity is a member of the following groups:
Event Log Readers
IIS_USERS
Performance Monitor Users
I've also seen the following question which seems to ask the same thing. The Microsoft article seems to suggest it might be a problem with ACLs on an event log and gives examples on how you can change SSDLs but I'd rather avoid that if at all possible.
EDIT:
I have another server running where the log is being populated fine. The custom identity was a member of administrators so I revoked that and rebooted, trying to purposely break it but I cant. Config is identical on both boxes and same identity used to run the MSI which creates the registry keys. Have run procmon on both (after doing a IISReset and spinning up the app pool again) to examine registry activity. Strange thing is - on the box that works you get 477 name not found records for my event source in the wrong places (Application, and a different Custom EventLog "MyCompany"). No hits for the place where it is logging which is "MyCompany\MyCompany.SiteCore". Whilst on the box which is broken, it does appear to be requesting to read the right key (albeit only 6 times) but you then get the Log4Net registry access error.
As I understand it EventStores are stored in the registry, so you only need write permission to registry to create or delete an EventStore. This is usually only needed once and most applications create this as part of the install procedure so that the application does not need to be run as Administrator during normal execution.
However your error message (in the question) includes the method DeleteEventSource from which I would deduce/guess that the EventSource does exist but is wrong in some way. So perhaps this is currently registered as writing to the event log named MyCompany and you are now trying to change it to "MyCompany\MyCompany.SiteCore" which requires you to delete the old eventsource and create a new one.
So it sounds like your installation routine is creating a different EventSource from the one that your application is actually using.
If that doesn't help, then I would suggest enabling internal logging for Log4net (but obviously not to the eventlog) which will probably give you more information.
Giving full permission to the registry key is not enough.
According to Microsoft
To create an event source in Windows Vista and later or Windows Server 2003, you must have administrative privileges.
The reason for this requirement is that all event logs, including security, must be searched to determine whether the event source is unique. Starting with Windows Vista, users do not have permission to access the security log; therefore, a SecurityException is thrown.
Starting with Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. To execute the code that accesses the security log, you must first elevate your privileges from standard user to administrator. You can do this when you start an application by right-clicking the application icon and indicating that you want to run as an administrator.
I think, contrary to the Apache documentation, log4net DOES need write access to the registry – or at least it does in my case. To prove this, I backed up the registry on the server where it wasnt working and granted IIS administrator privileges before spinning up sitecore. Sure enough it started logging away to the eventlog nicely and then when I exported the registry again to run a diff, there WAS a difference.
The value for the eventlogmessage file on my event source had been updated from:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
To
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
So I assumed that merely changing this value in the registry by hand would work.
But it didn’t.
So I ran procmon on the two servers I have: A=the working one, B=the failing one. Sure enough, on server B I have a line which says:
Operation: RegOpenKey, Path: HKLM\System\CurrentControlSet\Services\EventLog, Desired Access:Read/Write, Result: ACCESS DENIED.
I’ve traced through with Server A and in exactly the same place, the key is requested with Desired Access:Read.
Conclusion:
It seems unavoidable that I will need to grant my app pool identity administrator privileges in production for at least enough time to programatically do the necessary registry writes the first time from within log4net. I dont know why administrator; I have tried granting Full permissions to the entire eventlog node in the registry for my custom app to no avail. It seems to do something which I cannot identify or pin down. I will then revoke this privilege immediately after it starts to log and monitor whether subsequent installs knock out the functionality afterwards. (Hopefully not).
If anyone has any insight into this behaviour it would be greatly appreciated.