GRC53 Rule Set Migrated into GRC10

Gurus, has anyone encountered the following situation. We migrated our 53 rule set into GRC 10 using the Migration Tool. On the surface all of the rule objects seem to move across as they should. We then began to run our risk reports. We noticed that for the same user, in the same backend ECC system, we get varying results from our 53 Rule Set which is in our GRC10 system vs the 5.3 Rule Set executed from our old 5.3 system. We see more violations returned from our old 5.3 system; entire risks are not reported from the GRC10 system.
Consequently, I began reviewing the functions (actions/permissions). I picked a specific risk that was returned by the 5.3 system and reviewed it, line by line - comparing the 53 Rule Set in GRC10 against the 53 Rule Set in the 5.3 system. Everything lined up, with the exception of the activity values. In the 53 Rule Set that was migrated into GRC10 the activity values are single digits (1,2,5, etc) where as in the 5.3 System the activates are two digits (01, 02, 05, etc), Since the values are mainatined in SAP as double digits, could this be causing this? I would hope this is not the culprit, but I am unsure where else to turn.
I will say for those risks that were returned in the results, the activities in those functions were single digits as well.

Hi Penn,
Can you check if your default SoD risk level is "Critical" and hence all the conflicts are not being thrown in 10.0
There is an SAP Note 1632864 where you need to maintain parameter 1024 and se tthe default risk level to High. Since there is no option of All in 10.0 similar to 5.3
Thanks and Best Regards,
Srihari.K

Similar Messages

Rule set migration from GRC 5.3 to GRC 10.0

Hello everyone,
I ask you this question: if I want to migrate from GRC 5.3 to GRC 10.0, can I keep my old custom rule set with no modification or I have to make some changes to it to import in GRC 10?
Thankyou in advance for the answers
Greetings
Gianluca
Edited by: Gianluca Mocini on Apr 1, 2011 5:33 PM

Hi,
The migration utility is very simple. You install it on GRC 5.3 box and then select the items you want to migrate. It will generate tab limited text files and you can use those files to import data into 10.0 box.
Regards,
Alpesh

How to migrate Master Data (Rule set etc.) from GRC 5.3 to 10.1 without using the "Migration Tool"

Greetings,
We are currently on GRC 5.3 SP 18 (Java ONLY) and migrating to GRC 10.1. I referred the Migration Guide which outlines that GRC 5.3 needs to be upgraded to SP 20 as pre-requisite for using the "Migration Tool" . Our BASIS team is reluctant to perform this upgrade from SP 18 to SP 20.
Having said thus, I'm exploring options of migrating data from 5.3 to 10.1 without using the "Migration Tool:.
Rule set Migration:
I'm in the process of preparing the 9 different files (listed below) and later utilize the "Upload Rule" option for migrating the Rule set data from 5.3 to 10.1.
While I'm able to gather data for most of the files I'm not sure how can I obtain the data pertaining to the two files (Function Actions and Function Permissions) underlined and highlighted in Red below.
1. Business Process
2. Function
3. Function Business Process
4. Function Actions
5 .Function Permissions
6. Rule Set
7. Risk
8. Risk Description
9. Risk Rule Set Relationship
10. Risk Owner Relationship
Can someone please enlighten me and share their experience with regards to this exercise. Really appreciate your help !
- Janantik.

I have done this successfully before. Because you are having issues, I would NOT recommend using the migration tool to move the ruleset. Instead:
1. Download the ruleset files from 5.3
2. The 5.3 tcode-permission file, which defines which tcode permissions from SU24 need to be checked during risk analysis, needs to be split into the two files you mention above in red.
FUNCTION_ACTION : this file represents S_TCODE objects and TCD fields mapped to each function (Function to Tcode relationship). In the 5.3 file, you will filter on object S_TCODE and field TCD, and you will get a complete list that now represents "FUNCTION_ACTION". BUT instead of having all the jumbled permission info, you will just have 3 columns: Function - Tcode - Status.
3. The remaining permissions that are left over, after taking out the S_TCODE -TCD items, represent the "FUNCTION_PERMISSION" file in GRC 10.
4. Manually create the excel spreadsheets for each file.
5. Copy and past each sheet to a unique .txt file.
6. Upload the ruleset manually through SPRO-->GRC-->Access Control-->Access Risk Analysis-->SoD Rules-->Upload SoD Rules.
7. Select each file and then upload to the correct Logical Group.
This is a huge pain, but it works. Let me know how this goes and if you need any assistance.
-Ken

Non existing value EC for M_BEST_BSA / BSART used in rule set

Hello,
while implementing the 2010 rule set updates into our system, we realized that there is a value used that is not existing in the system.
It is for object M_BEST_BSA, field BSART. The value is EC.
In the rule update document from Q2 2010, there is the following comment:
5. PR02 u2013 Maintain Purchase Order u2013 Upon review of this function with the rules mini-council, the decision was made to remove document type from the rules. Previously, we delivered document types EC, FO and NB with our rules. However, the majority of customers create custom document types for purchasing. Many customers did not customize the rules, which results in only those users that had the standard EC, FO and NB document types being reported as having a risk. Users who had the custom document types would not be reported, which results in false negative reporting. Therefore, the decision was made to remove document type from our delivered rules. This will force each customer to review their document types and edit this function to include all relevant document types so all users who have a risk are shown.
However the value is still enabled in function PR04, even though it is not a valid value for field BSART. It is not existin in table T161, which holds the PO document types. It does not seem to exist since at least release 4.6C
The value is inherited from the transactions ME28 and ME29N
Does anyone know what it is about and why the value still is considered a standard value?
I know this does not give me false conflicts, as the BSART values are used in condition OR.
Why is the value not just removed, if it is not a valid value at all?
edit:
Sorry, forgot to mention, we use CC4.0 in an ECC6.0 system
end of edit:
Regards,
Thomas Schaeflein
IBM
Edited by: Thomas Schaeflein on Jan 26, 2011 4:14 PM

Start by saying bump.
I've still no word from Adobe if they are doing anything with
this problem. Any one had any replys from Adobe on it? Any one
found a work around with recoding queries?

Migrating HBR Sequences into 11.1.2.x as Rule Sets

Hi, has anyone been able to migrate sequences into Calc Manager? With the method I'm trying, Calc Manager recognizes the rules and variables in the sequence(s) (will skip then when the Skip option selected), but the rule set does not appear (verified by <Find><Contains> search.
-Vince

Hi, has anyone been able to migrate sequences into Calc Manager? With the method I'm trying, Calc Manager recognizes the rules and variables in the sequence(s) (will skip then when the Skip option selected), but the rule set does not appear (verified by <Find><Contains> search.
-Vince

Updation of Rule-set in GRC10

Hi,
There is a requirement for us to update few risks(objects within the risk) for our non-business ruleset. What is the best suggested method to do this?
->Directly update from NWBC
->Download Rule-set and upload from SPRO
->Transport
If any body can share their suggestions and steps, it would be great.
Thanks,
Sabitha

Hello Sabitha,
This is because you haven't created the connectors in DEV. do you have that connectors in SM59?? I recoomend to create the connectors and associate the to the logical system just to keep all the systems with the same info. you can create the connectors but it's not neccesary to fill all the data in SM59. Just create the connector with the name would be fine.
If i modify the ruleset based on the connector group in development and transport the ruleset would all the physical systems still be listed in the drop down in Quality and Prod
Yes, this will be deleted only if you transport the logical system configuration from DEV and it's not related to SoD rules transport.
If we modify the ruleset based on connector group in development and transport , would it cause any inconsistency as it looks like the Quality and Prod the physical connectors are linked to the ruleset
No. if you are working with the logical system and you haven't uploaded rules to the physical ones it has no effect.
From your comment I understand that it does not matter about the physical systems as rule generation would take care of generating/linking the ruleset based on the systems assigned to the Connector Group/Logical Systems- If this is the case I am wondering why in development system even after the generation of rule-sets the physical systems are not available
This is because you haven't created the connector or you haven't linked the connectors to te connector groups or you haven't enabled the connectors for the auth scenario.
When generating rules the system generates the rules for the necessary logical systems. since you have none in DEV it wont generate rules for your scenario. So in the escenario you are describing in DEV with logical connectors but no physical ones you shouldn't be able to execute a risk analysis there.
Cheers,
Diego.

Do you trust the SAP standard rule set ?

Hello all,
I have the impression that, too often, the SAP standard ruleset has been taken for granted : upload, generate and use. Here is a post as to why not to do so. Hopefuly, this will generate a interesting discussion.
As I have previously stated in other threads, you should be very careful accepting the SAP standard rule set without reviewing it first. Before accepting it, you should ensure that your specific SAP environment has been reflected in the functions. The 2 following questions deal with this topic :
1. what is your SAP release ? ---> 46C is different than ECC 6.0 in terms of permissions to be included in the function permission tab. With every SAP release, new authorization objects are linked to SAP standard tcodes. Subsequently some AUTHORITY-CHECK statements have been adapted in the ABAP behind the transaction code. So, other authorizations need to provided from an implementation point of view (PFCG). And thus, from an audit perspective (GRC-CC), other settings are due when filtering users' access rights in search for who can do what in SAP.
2. what are your customizing settings and master data settings ? --> depending on these answers you will have to (de)activate certain permissions in your functions. Eg. are authorization groups for posting periods, business areas, material types, ... being used ? If this is not required in the SAP system and if activated in SAP GRC function, then you filter down your results too hard, thereby leaving certain users out of the audit report while in reality they can actually execute the corresponding SAP functionality --> risk for false negatives !
Do not forget that the SAP standard ruleset is only an import of SU24 settings of - probably - a Walldorf system. That's the reason SAP states that the delivered rule set is a starting point.
So, the best practice is :
a. collect SAP specific settings per connector in a separate 'questionnaire' document, preferably structured in a database
b. reflect these answers per function per connector per action per permission by correctly (de)activating the corresponding permissions for all affected functions
You can imagine that this is a time-consuming process due to the amount of work and the slow interaction with the Java web-based GRC GUI. Therefore, it is a quite cumbersome and at times error-prone activity ...... That is, in case you would decide to implement your questionnaire answers manually. There are of course software providers on the market that can develop and maintain your functions in an off-line application and generate your rule set so that you can upload it directly in SAP GRC. In this example such software providers are particularly interesting, because your questionnaire answers are structurally stored and reflected in the functions. Any change now or in the future can be mass-reflected in all (hundreds / thousands of) corresponding permissions in the functions. Time-saving and consistent !
Is this questionnaire really necessary ? Can't I just activate all permissions in every function ? Certainly not, because that would - and here is the main problem - filter too much users out of your audit results because the filter is too stringent. This practice would lead too false negatives, something that auditors do not like.
Can't I just update all my functions based on my particular SU24 settings ? (by the way, if you don't know what SU24 settings are, than ask your role administrator. He/she should know. ) Yes, if you think they are on target, yes you can by deleting all VIRSA_CC_FUNCPRM entries from the Rules.txt export of the SAP standard rule set, re-upload, go for every function into change mode so that the new permissions are imported based on your SU24 settings. Also, very cumbersome and with the absolute condition that you SU24 are maintained excellent.
Why is that so important ? Imagine F_BKPF_GSB the auth object to check on auth groups on business areas within accounting documents. Most role administrator will leave this object on Check/Maintain in the SU24 settings. This means that the object will be imported in the role when - for example - FB01 has been added in the menu. But the role administrator inactivates the object in the role. Still no problem, because user doesn't need it, since auth groups on business areas are not being used. However, having this SU24 will result in an activated F_BKPF_GSB permission in your GRC function. So, SAP GRC will filter down on those users who have F_BKPF_GSB, which will lead to false negatives.
Haven't you noticed that SAP has deactivated quite a lot of permissions, including F_BKPF_GSB ? Now, you see why. But they go too far at times and even incorrect. Example : go ahead and look deeper into function AP02. There, you will see for FB01 that two permissions have been activated. F_BKPF_BEK and F_BKPF_KOA. The very basic authorizations needed to be able to post FI document are F_BKPF_BUK and F_BKPF_KOA. That's F_BKPF_BUK .... not F_BKPF_BEK. They have made a mistake here. F_BKPF_BEK is an optional auth object (as with F_BKPF_GSB) to check on vendor account auth groups.
Again, the message is : be very critical when looking at the SAP standard rule set. So, test thoroughly. And if your not sure, leave the job to a specialized firm.
Success !
Sam

Sam and everyone,
Sam brings up some good points on the delivered ruleset. Please keep in mind; however, that SAP has always stated that the delivered ruleset is a starting point. This is brought up in sap note 986996     Best Practice for SAP CC Rules and Risks. I completely agree with him that no company should just use the supplied rules without doing a full evaluation of their risk and control environment.
I'll try to address each area that Sam brings up:
1. Regarding the issue with differences of auth objects between versions, the SAP delivered rulset is not meant to be version specific. We therefore provide rules with the lowest common denominator when it comes to auth object settings.
The rules were created on a 4.6c system, with the exception of transactions that only exist in higher versions.
The underlying assumption is that we want to ensure the rules do not have any false negatives. This means that we purposely activate the fewest auth objects required in order to execute the transaction.
If new or different auth object settings come into play in the higher releases and you feel this results in false positives (conflicts that show that don't really exist), then you can adjust the rules to add these auth objects to the rules.
Again, our assumption is that the delivered ruleset should err on the side of showing too many conflicts which can be further filtered by the customer, versus excluding users that should be reported.
2. For the customizing settings, as per above, we strive to deliver rules that are base level rules that are applicable for everyone. This is why we deliver only the core auth objects in our rules and not all. A example is ME21N.
If you look at SU24 in an ECC6 system, ME21N has 4 auth objects set as check/maintain. However, in the rules we only enable one of the object, M_BEST_BSA. This is to prevent false negatives.
3. Sam is absolutely right that the delivered auth object settings for FB01 have a mistake. The correct auth object should be F_BKPF_BUK and not F_BKPF_BEK. This was a manual error on my part. I've added this to a listing to correct in future versions of the rules.
4. Since late 2006, 4 updates have been made to the rules to correct known issues as well as expand the ruleset as needed. See the sap notes below as well as posting Compliance Calibrator - Q2 2008 Rule Update from July 22.
1083611 Compliance Calibrator Rule Update Q3 2007
1061380 Compliance Calibrator Rule Update Q2 2006
1035070 Compliance Calibrator Rule Update Q1 2007
1173980 Risk Analysis and Remediation Rule Update Q2 2008
5. SAP is constantly working to improve our rulesets as we know there are areas where the rules can be improved. See my earlier post called Request for participants for an Access Control Rule mini-council from January 28, 2008. A rule mini-council is in place and I welcome anyone who is interested in joining to contact me at the information provided in that post.
6. Finally, the document on the BPX location below has a good overview of how companies should review the rules and customize them to their control and risk environment:
https://www.sdn.sap.com/irj/sdn/bpx-grc
Under Key Topics - Access Control; choose document below:
    o GRC Access Control - Access Risk Management Guide   (PDF 268 KB)
The access risk management guide helps you set up and implement risk
identification and remediation with GRC Access Control.

Downloading a single rule set out of N rule sets.

HI All,
We have defined 4 Rule sets for one particular system. Out of these one is the global rule set. Now, my requirement is to have oe more rule set, with 80% rules from global and then add the rest 20% myself. Would like to know if there is any way we can achieve this efficiently, other than creating manually all the 80% rules from GLOBAL rule set.
Thanks a lot in advance.
Regards,
Hersh

HI Jose,
Well what you guided was perfectly fine an true in case of making changes to GLOBAL rule set. But any idea how we can make a new rule set out of the custom rule set i have already made.
I have , in all 4 rule sets present at the moment in GRC - GLOBAL, CUST -1,2 and 3. Now, my requirement is to have a copy of CUST1 into new rule set CUST4, and I manually later on need to update CUST4 for some more risks in it. The problem i am facing is whenever i download the existing rule sets, it is not giving me an option to download just CUST1, but all of four rule sets get downloaded together. Whereas, i need just a copy of CUST1. Any ideas on this?
Regards,
Hersh.

GRC Risk analysis reports are not checking all possible risk conflicts set up in the rule set that lead to risks.

Dear All,
After running the risk analysis it shows only the first conflict for a risk in the rule set (Rule ID 0001). We have already Generated SOD ruleset. Also during migration from 5.3 to AC10.1 all the rulesets were imported properly.
What could be reason??
Thanks for your help.
Regards,
Abhisshek

Abhisshek,
there is already a thread with the same question: Dear all I only get result for one rule id and not with others what should be an issue?
Regards,
Alessandro

Need information on the new RAR Rule Architect/Rule Set functions

Does anyone have any information on the new 5.3 functions listed under Rule Architect/Rule Sets, specifically the Compare function?
My 5.3 Config manual mentions this area but doesn't describe anything about it. I have a request from our user group and need to determine if this can fit that request.
What they are looking for is an easy way to compare our RAR Rule Set with the latest SAP version (Q2 2010 is the most recent I believe). Just from the screen shots, it looks like we could maybe use the Rule Sets functions for that. Load the new SAP one into RAR as a separate ruleset and then run this Compare function. However I haven't been able to find any documentation on this function, so I don't know if it really does what we are looking for.
Thanks.

Hi,
the error 'NullPointerException ' is very common error in GRC.
kindly search, you will find lots of threads and notes on thi.
check you permission TXT file. It contain null value some where.
especially check SD01 & SD02 tcodes.
Also open permission file in word and check all TAB's and ENTER's in technical view.
Regards,
Surpreet

TS2646 Settings to record in on Canon HD Vixia HG20 for easy migration into iMovee'11 v.9.0.9? It would be most helpful to list what the best possible settings are.

So, what are the best settings to record in using Canon HD Vixia HG20 for easy migration into iMovee'11 v.9.0.9?
It would be most helpful to list what the best possible settings are.
frame rate?
format? FXP?

I suggest filming in 30P with this camera. That should be the MXP setting.
You could also use 30i which would be the FXP setting.
You will get the best results in iMovie by shooting progressive.

CC / RAR 5.2 - Multiple Rule Set Question

How does the system handle the use of multiple rule sets in CC / RAR 5.2?
For example, letu2019s say I want to keep a standard SAP rule set in tact to use for testing and comparison in RAR, but I also want to load another one.
I realize that only 1 can be the u201CDEFAULTu201D so what does that mean? I know that a risk analysis is only run against the rule set you set as default. I also know that you can select the rule set to use in processing when you manually run either through Informer or Configuration tab a risk analysis. What I am really concerned with is what happens if you take the results to u201Cmanagement reportsu201D from 2 different rule sets?
First, can you even do it?
Second, if you can, then I think you must have to come up with a different RISKID configuration schema for each rule set otherwise, I do not see how you can differentiate from which rule set the violation is generated. That said, you will also need to export the report information into Excel and make any u201Crule set sortu201D there as I donu2019t see a way to do it directly in RARu2026.maybe a future improvement?
Can anyone confirm the impact of multiple rule sets and how you manage them?
Regards,
Greg

Greg,
You can maintain the different severity levels for different Rule Sets. For example, in one Rule Set you can keep the "Critical" Risks and in other you can keep "High", "Medium" & "Low". Run your analysis against first Rule Set if you want to know the "Critical" Risks and second Rule set you can use for rest of the severity levels. I hope this way you can manage your multiple Rule Sets in RAR.
Thanks,
Tavi
SAP Security & GRC Consultant.

GRC 10: Default Rule sets

Hi All.
i am wondering whether we have default rule set for GRC10 as we found with GRC 5.3. Where do I find them in GRC 10 software download?
rEgards,
Faisal

In GRC10 default rule set are available by BCset :
GRAC_RA_RULESET_COMMON
GRAC_RA_RULESET_JDE
GRAC_RA_RULESET_ORACLE
GRAC_RA_RULESET_PSOFT
GRAC_RA_RULESET_SAP_APO
GRAC_RA_RULESET_SAP_BASIS
GRAC_RA_RULESET_SAP_CRM
GRAC_RA_RULESET_SAP_ECCS
GRAC_RA_RULESET_SAP_HR
GRAC_RA_RULESET_SAP_NHR
GRAC_RA_RULESET_SAP_R3
GRAC_RA_RULESET_SAP_SRM

Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA

Issue Summary
In Java 1.7 Update 71, Java 1.7 Update 72 and Java 1.8 Update 25 Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA. We've noticed this with Oracle Forms and Reports 11g where we have forms that specify Java 1.6 Update 20. We used to be able to specify Java 1.6 Update 26 in our Ruleset, but now the only version a that works in our ruleset is Java 1.6 Update 20 which is the same version requested by the JPI-Version attribute of the jar. The long term solution would be to upgrade Oracle Forms and Reports, however this isn't currently in the cards.
RuleSet.xml Test
Ruleset.xml
1
2
3
4
5
6
7
8
9
10
11
<ruleset version="1.0+">
<rule>
   <id location="*.javatester.org" />
   <action permission="run" version="1.6*" />
</rule>
<ruleset version="1.0+">
<rule>
   <id location="*.internaldomain.name" />
   <action permission="run" version="1.6*" />
</rule>
</ruleset>
Test 1 (Control)
Installed Java Versions:
– 1.7 Update 51 b13 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
Deployment Ruleset works as expected for both URLs
Test 2
Installed Java Versions:
– 1.7 Update 72 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
The RuleSet works for JavaTester.org however on internaldomain.name we get the following error:
With the trace logging turned on, I suspected the version attribute supplied by the RIA. I was able to trick Java by adding the following to my system deployment.properties file:
deployment.javaws.jre.0.product=1.6.0_20
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.enabled=true
Because the RIA requests 1.6.0_20 it matches 1.6* from the deployment ruleset sooner than 1.6.0_26. However, if 1.6.0_20 is not available 1.6.0_26 should match according to the Deployment Rule Set documentation:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
The version of the JRE that is used is determined by the following order of precedence:
1. The current version of the JRE is used if it is available and matches both the version attribute and the version requested by the RIA.
2. The latest available version of the JRE is used if it matches both the version attribute and the version requested by the RIA.
3. The current version of the JRE is used if it is available and matches the version attribute.
4. The latest available version of the JRE is used if it matches the version attribute.
If no version is available that meets the criteria, then the RIA is blocked, and a message is shown to the user. To provide a custom message, include the message element.
As a result:
If Java 1.6.0_20 is listed in the version requested by the RIA and 1.6.0_20 is listed in the deployment.properties file, #1 matches.
If Java 1.6.0_20 is listed in the version requested by the RIA, but 1.6.0_20 is NOT listed in the deployment.properties file the #1 SHOULD match, but doesn’t. It used to match up-to and including JRE 1.7 Update 51 however the ruleset appears to no longer match in subsequent versions.
#2 should never match with our current Deployment Ruleset. It would match if we specified 1.7* as a version in the Ruleset.xml.
#3 used to be broken as well after JRE 1.7 Update 51 however this bug has been marked as fixed. See: http://bugs.java.com/view_bug.do?bug_id=8032781
I have reproduced this issue with Java 1.7 Update 71, Java 1.7 Update 72, and Java 1.8 Update 25 when one of these versions are installed with Java 1.6 Update 26.

I can't seem to edit this post anymore, for some odd reason.
So here goes;
I found this post in NVIDIA's knowledge base;
When installing an after-market graphics card into a certified Windows 8 PC with UEFI enabled, the s...
The interesting parts in this post are as follows;
When an after-market graphics card is installed into a motherboard with UEFI enabled in the system BIOS, or if the system is a certified Windows 8 PC with Secure Boot enabled, the system may not boot.
UEFI is a new system BIOS feature that is provided on most new motherboards. A UEFI system BIOS is required in order for the Windows 8 Secure Boot feature to work. Secure boot is enabled by default on certified Windows 8 PCs.
In order to get the PC to boot with a graphics card that does not contain UEFI firmware, the end-user must first disable the secure boot feature in the system's SBIOS before installing the graphics card.
Note: Some system SBIOS's incorporate a feature called compatibility boot. These systems will detect a non-UEFI-enabled firmware VBIOS and allow the user to disable secure boot and then proceed with a compatibility boot. If the system contains a system SBIOS the supports compatibility boot, the user will need to disable secure boot when asked during boot process
This leads me to believe that the BIOS update that wrecked my setup was 9SKT58A/9SJT58A, which only contains one change;
"Adds support for updating BIOS from a WIN7 BIOS to a WIN8 BIOS".
I've just ordered a cheap UEFI-compatible GT640 from Gainward, so I hope I'll be able to try that out this weekend.

SoD rule set Download issue

Hi All,
While downloading the SoD rule set (Global), I am not getting the data for Function-Action and Function-Permission, except these, rest of the data are coming.
But, I can get to see these data under tables: GRACFUNCACT and GRACFUNCPRM.
so obviously we can't have these data exported from table and to get converted into .txt format to upload SoD.
GRCFND_A is at SP14.
Please help in getting this issue resolved.
Thanks,
Ameet

Hi Ameet,
You have to reactivate it each time you install a SP in order to get the updates.
If you develelop your own SoD ruleset you wont use the SAP standard functions and risk, so reactivate the BC Set wont cause any problem.
If you change the standard functions and risks (which is wrong) such changes will be overwritten when reactivate the BC Set.
After reactivating the BC set you'll be able to download SoD rules fom the logical system SAP_R3_LG.
Cheers,
Diego.

GRC53 Rule Set Migrated into GRC10

Similar Messages

Maybe you are looking for