srigutha https://docs.microsoft.com/archive/blogs/srigutha/feed.xml Wed, 17 Apr 2019 03:50:25 GMT en-US hourly 1 Project Professional needs to be installed to open the project. https://docs.microsoft.com/archive/blogs/srigutha/project-professional-needs-to-be-installed-to-open-the-project Mon, 25 Apr 2016 00:08:24 GMT https://blogs.msdn.microsoft.com/srigutha/?p=65
  • Open the Project from the Project Center
  • Navigate to the Project Schedule
  • On the ribbon, click on edit and select edit in Project Professional
  • The Project Professional opens however, you will receive the following error.
    • ProjectServerError This is because of a bug and the fix is released in April 2016 CU for Project Server If the fix does not help, some of the troubleshooting steps that may help are below. 1. IE settings >> Internet Options >> Security >> Trusted Sites >> and check if the root SharePoint site is added to the trusted sites. 2. If the users who is having the issue has both Project 2010 and Project 2013 on client machines, then add the PWA URL to the Project 2010]]>         Migrate Users in SharePoint :: Users having access issues after migration https://docs.microsoft.com/archive/blogs/srigutha/migrate-users-in-sharepoint-users-having-access-issues-after-migration Wed, 27 Feb 2013 22:33:00 GMT https://blogs.msdn.microsoft.com/srigutha/2013/02/27/migrate-users-in-sharepoint-users-having-access-issues-after-migration/ So, most of you might be knowing that SharePoint (MOSS 2007 and SP 2010) provides a stsadm commandlet called "stsadm -o migrateuser" to migrate an user from old domain account to new domain account. While the command is a blessing, it also comes with a curse..

    the stsadm –o migrateuser cmdlet does the following things (in the order specified below) when executed.  

    • Marks the “new login id” for deletion (if the “new login id” already has some permissions set)
    • Replaces the “old login id” to the “new login id” (when the “old login id” already has some permissions set)

    Look at the following for example,

    The following records are pulled from UserInfo table where there is a duplicate NTID present for a particular user. The actual NTID with number (73263) bears the UserID 427 while the duplicate id (i:0#-73263) has the user id as 1719.

    After running the stsadm -o migrateuser on the above mentioned user, below is the status of the UserInfo table for the same records..

    So what this means..

    Lets say, for example, if the actual NTID is associated to a group with Full Control permission and the duplicate NTID is associated to a group with Limited Access. After running the stsadm –o migrateuser on the user NTID, the actual NTID is
    removed from the group with Full Control permission and the duplicate NTID is replaced with the actual NTID in the group with Limited Access permission there by causing access related issues for the user.

    Bottom line, be vary of the above before running stsadm -o migrateuser cmdlet :)

     

     

     

    ]]>         SharePoint 2010 Search Query String Terms https://docs.microsoft.com/archive/blogs/srigutha/sharepoint-2010-search-query-string-terms Mon, 25 Feb 2013 02:01:00 GMT https://blogs.msdn.microsoft.com/srigutha/2013/02/25/sharepoint-2010-search-query-string-terms/ There is very limited documentation around what exactly the query string terms mean for SharePoint 2010 People Search. Thought would post little more information about the same.

    You might have notcied already that SharePoint 2010 is based on Keyword search (as opposed to Full text search in MOSS 2007) and uses some of the below Query Strings when constructing the URL's..

    • k = the keyword or the search term
    • v = the Default Sort
    • rm = Ranking model
    • ql = Query Language ID
    • s = Scope Name
    • cs = Contextual Scope
    • u = Contextual Scope URL
    • r = refinement

    A sample URL with query string parameters in the search center UI - https://intranet.MyCompany.com/SearchCenter/Pages/peopleresults.aspx?k=share&hs1=True&rm1=D9BFB1A1%2D9036%2D4627%2D83B2%2DBBD9983AC8A1&v1=name

    ]]>         Event ID : 2137 - Verify that the critical User Profile Application and User Profile Proxy Application timer jobs are available and have not been mistakenly deleted. https://docs.microsoft.com/archive/blogs/srigutha/event-id-2137-verify-that-the-critical-user-profile-application-and-user-profile-proxy-application-timer-jobs-are-available-and-have-not-been-mistakenly-deleted Wed, 14 Dec 2011 12:37:54 GMT https://blogs.msdn.microsoft.com/srigutha/2011/12/14/event-id-2137-verify-that-the-critical-user-profile-application-and-user-profile-proxy-application-timer-jobs-are-available-and-have-not-been-mistakenly-deleted/ After installing August 2011 CU on SPS 2010, you will notice the following Event in the application logs of your App servers.

      <EventData>

       <Data Name="string0">Verify that the critical User Profile Application and User Profile Proxy Application timer jobs are available and have not been mistakenly deleted.

    A required timer job for a User Profile Application or User Profile Application Proxy is missing.

    The repair action will recreate missing timer jobs required for the User Profile Application or User Profile Application Proxy. For more information about this rule, see "https://go.microsoft.com/fwlink/?LinkID=159660".

    </Data>

      </EventData>

     

    This is a known issue and is corrected (infact the rule check is ignored) in October CU 2011. For more details, refer to the KB https://support.microsoft.com/kb/2622705

    ]]>