Friday, 21 June 2013

Java Script to stop a form From Saving

In some condition we need that form should not be allowed to save:

To stop the save event in Javascript all you need is this
event.returnValue = false;

 Method in CRM 2011 is the following one:
Xrm.Page.context.getEventArgs().preventDefault();

preventDefault : Cancels the save operation, but all remaining handlers for the event will still be executed.

Sunday, 16 June 2013

Snap Shot Of Orion Release Ms CRM

It has been very fascinating writing the blog and reaching out latest on MS CRM to all  MS CRM Developers.
After Polaris release MS is really working hard for the better Furture road map on upcoming Orion release.

Main Feature of polaris release :
 1 .CRM was going to be supported across multiple browsers
 2. CRM was going support the Custom workflow in online.
 3. Rich user experience , reducing the number of click on form.

Main Feature of Orion release :
1. Rich UI as window 8 .
2.Social upgrade : Support on Windows phone and Ipad.
3.developers will be able to add apps inside of Office clients, including Microsoft Outlook

MS CRM will turn really a haunting hunt for All.

Auto Group Management Off Feature in MS CRM 2011

The Auto Group Management option is used to determine how the appropriate users and the appropriate computers are added to the security groups. Microsoft Dynamics CRM can add the users and the computers. Or, a user who has appropriate permissions in the Microsoft Dynamics CRM security groups can manually add the users and the computers.

For the Auto Group Management option, use one of the following methods. Use Method 1 to set the AutoGroupManagementOff option to "false" and to have Auto Group Management turned on. Use Method 2 to set the AutoGroupManagementOff option to "true" and to have Auto Group Management turned off.

Note The Auto Group Management option can be used only if you are installing Microsoft Dynamics CRM by using pre-created Active Directory security groups.

Note: When import organization wizard runs to import organization it considers AutoGroupManagementOff registry value to assign necessary SQL permissions on the imported database. If it's set to 1 import org wizard will not assign SQL permissions on the database, so SQL permissions may need to be assigned through SQL management studio after the import wizard succeeds. If it's set to 0 import org wizard will assign SQL permissions on the database. By default AutoGroupManagementOff reg value is set to 0.



Method 1: Set the AutoGroupManagementOff option to "false"

Because this setting is the default setting, you do not have to add anything to the configuration file. However, the following procedure is an example that describes how to set the AutoGroupManagementOff option to "false."

Create an XML configuration file that uses the syntax in the following example. Modify the variables as appropriate. To modify the variables that are in this example, refer to step 6 in the "Installation option 2: Use the pre-created Active Directory security groups when you install Microsoft Dynamics CRM" section as a guideline.

In this example, the XML file is named Config_precreate.xml. The domain name is microsoft.com. The Active Directory hierarchy is as follows:
  • root domain
    • Company Name OU
      • Company Name OU
Sample code

<CRMSetup>
   <Server>
         <Groups>
  <Groups autogroupmanagementoff="false">
            <PrivUserGroup>CN=PrivUserGroup,OU=Company Name,OU=Company Name,DC=microsoft,DC=com</PrivUserGroup>
          <SQLAccessGroup>CN=SQLAccessGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</SQLAccessGroup>
            <UserGroup>CN=UserGroup,OU=Company Name,OU=Company Name,DC=microsoft,DC=com</UserGroup>
            <ReportingGroup>CN=ReportingGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</ReportingGroup>
 <PrivReportingGroup>CN=PrivReportingGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</PrivReportingGroup>
 </Groups>
</CRMSetup>

Method 2: Set the AutoGroupManagementOff option to "true"


  1. Create an XML configuration file that uses the syntax that is in the following example. Modify the variables as appropriate. To modify the variables that are in this example, refer to step 6 in the "Installation option 2: Use the pre-created Active Directory security groups when you install Microsoft Dynamics CRM" section as a guideline.

    In this example, the XML file is named Config_manageoff.xml. The domain name is microsoft.com. The Active Directory hierarchy is as follows:
    • root domain
      • Company Name OU
        • Company Name OU
    Sample code

    <CRMSetup>
       <Server>
             <Groups AutoGroupManagementOff="true">
                <PrivUserGroup>CN=PrivUserGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</PrivUserGroup>
              <SQLAccessGroup>CN=SQLAccessGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</SQLAccessGroup>
                <UserGroup>CN=UserGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</UserGroup>
                <ReportingGroup>CN=ReportingGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</ReportingGroup>
     <PrivReportingGroup>CN=PrivReportingGroup,OU=Company Name,OU=Company Name, DC=microsoft,DC=com</PrivReportingGroup>
      </Groups>
        </Server>
    </CRMSetup>
    
  2. Add the appropriate user accounts and the appropriate computer accounts as members of the following groups.

    Note You must follow this step only if the AutoGroupManagementOff option is set to "true."

    PrivUserGroup
    • The account that the CRMAppPool application pool uses
    • The account that the ASP.NET process model uses
    • The user account that runs the Microsoft Dynamics CRM installation
    • The computer account on which the Microsoft Dynamics CRM-Exchange E-mail Router will be installed
    ReportingGroup
    • All Microsoft Dynamics CRM user accounts (this includes the user who is installing Microsoft Dynamics CRM)
    SQLAccessGroup
    • The account that the CRMAppPool application pool uses
    • The account that the ASP.NET process model uses
    UserGroup
    • All Microsoft Dynamics CRM user accounts (this includes the user who is installing Microsoft Dynamics CRM)
    PrivReportingGroup
    • The computer account on which the Microsoft Dynamics CRM Data Connector for Microsoft SQL Server Reporting Services will be installed
    To add the accounts, follow these steps for each group in the list:
    1. Log on to the domain controller server as a user who has domain administrator permissions.
    2. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
    3. In the navigation pane, expand the tree to the node that contains the security group, right-click the security group, click Properties, and then click the Members tab.
    4. To add a user account, click Add, and then click OK. To add a computer account, click Object Types, click to select the Computers check box, and then click OK.
  3. To verify which account the CRMAppPool application pool uses, follow these steps on the computer that is running the Microsoft Dynamics CRM server:
    1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.
    2. Expand the computer name.
    3. Expand Application Pools.
    4. Right-click CRMAppPool, click Properties, and then click the Identity tab.
    The NetworkService account and the LocalSystem account are both represented by the "domainname\computername $" account. Therefore, if you must add the NetworkService account or the LocalSystem account to a security group, you must add the "domainname\computername $" account.

    If the Configurable option is selected, you must add the specified user account to the security group. The specified user account appears in a text box.
  4. To verify the account that the ASP.NET process model uses, follow these steps on the Microsoft Dynamics CRM server:
    1. In Windows Explorer, open the following folder:
      C:\WINNT\Microsoft.NET\Framework\v1.1.4322\CONFIG
    2. Right-click Machine.config, click Open With, and then click Notepad.
    3. Search for the word "username" in the text. The file contains multiple instances of the word. Locate the fifth instance of "username" that is in the text. The value for the fifth instance of "username" is the account that the ASP.NET process model uses.
    The SYSTEM account and the computer account are both represented by the "domainname\computername $" account. Therefore, if you must add the SYSTEM account or the computer account to a security group, you must add the "domainname\computername $" account.

    If a user name is specified in the Machine.config file, you must add the specified user account to the security group.

Friday, 14 June 2013

Waits and Timeouts in Dynamics CRM Workflows When to Wait, When to Timeout

Check Condition and Wait Condition as the flow in workflow: they provide the foundation for implementing logic in business processes. Of the two constructs, Check Condition is easier to understand: You check to see if a condition is true, and then do something if it is.
Wait conditions introduce a time dimension to your processes, and one of the reasons they’re a little harder to learn is that they come in two flavors: Wait and Timeout.
The wait and timeout conditions are both important ways of pausing a process, and they seem similar, at least at first. As it turns out, they serve quite different functions, and I’ll try to clarify them here with a brief explanation and a couple examples:
Use Wait when you want a work process to pause until a condition changes. Some common examples of the kinds of conditions you might Wait for include:
  • Wait until an assigned task is completed
  • Wait until the status or status reason of a record changes
  • Wait until the value of an attribute in a related entity changes
Use Timeout when you want a work process to pause until a specified date, for a specified period of time, or until you reach a date relative to the value of a CRM record’s date field. Some examples of these include:
  • Timeout until an Opportunity record is “overdue” (the current date is greater than the opportunity’s estimated close date)
  • Timeout until September 1, 2009 (maybe there’s a conference coming up on September 8 and you want to send a one-week reminder email to attendees)
  • Timeout until one week has passed since a new Account record was created
A timeout is pretty easy to understand once it’s created, but creating it is the tricky part. If you need to add a timeout condition to a workflow process, follow these steps in the process designer:
  1. Click the Add Step drop-down menu, and select Wait Condition.
  2. Click the <condition> (click to configure) link to open the Specify Condition dialog.
  3. From the drop-down list in the first column, select Process (in the Local Values section), and tab to the second column.
  4. Select Timeout from the drop-down.
  5. Tab to the next column and select Equals (the only option)
  6. Tab to the next column and then use Dynamic Values to set the timeout period relative to the Est. Close Date field, performing the next three steps in the Dynamic Values section:
  7. Select “7″ in the Day selector on the first row.
  8. Select After in the drop-down on the second row.
  9. Make sure that Opportunity is selected in the third row, and then select the Est. Close Date field in the fourth row. The Specify Condition dialog should now look like this:

This takes a little getting used to, but after you do it a few times you get the hang of it.