Failed to retrieve the AzMan Scope

Hi Fellows,
Yesterday, I was creating a Commerce Server environment which was to co-exist in a existing MOSS installation on the same box.

NOTE: Bare in mind folks, if you have DC and MOSS on the same box, I would not recommend installing Commerce Server on to the same box. DC makes Commerce Server impossible to work. My recommendation keep DC separate and then you may install Commerce and MOSS on the same machine/VM/box.

While restoring Commerce Server I faced a strange issue whereby web-services (catalog/marketing/orders/profiles) seem to work fine and correctly opened up in browser. However after configuring business application with corresponding web-services, Catalog Manger threw error when clicking to expand product catalog.


Solution: (Provided by: http://microsoftblog.co.in/commerceserver/filed-to-retrieve-the-azman-scope/)

Follow below steps to fix this problem.

• Open CatalogAuthorizationStore.xml file in Authorization manager.
• Right click on “CatalogandInventorySystem” and select “New Scope”.
• Give scope name as “CatalogScope_CatalogName” – In our context it’s “CatalogScope_Books”.
• Right click on "Task Definitions" and click on "New Task Definition". Click "Add" button and select appropriate tasks & operations.
• Right click on "Role Defintions" and click on "New Role Definiton". Click "Add" button and select appropriate roles.
• Right click on "Role Assignments" and click on "New Role Assignment". Select appropriate roles and press OK button.
• Make sure you add your windows id to the role also the service account used by your web application using Azman.msc

Cheers,

Commerce Server 2007 - Fetch Product Catalog

Hi Fellows,

Been quiet a while since I blogged last. These days am understanding nuts and bolts of another Microsoft Product i.e. Microsoft Commerce Server 2007/2009 and how they sync with Microsoft SharePoint Server 2009. Watch out for my up-coming blogs on Commerce Server.

Just to give you guys a Sneak Peak of what I have done so far, take a look at the code below which gets you Product Catalog Object by using Catalog System API's:

[CODE]

internal static ProductCatalog GetCSCatalog(String SiteName, String AuthorizationPolicyPath, String CatalogName)
{

try
{
//Accessing the site agent of a hypotheticla site BuyOnline
CatalogSiteAgent catalogSiteAgent = new CatalogSiteAgent();
catalogSiteAgent.SiteName = SiteName;



//Here its assumed that the context under which the method runs
// is already added in the AZMAN for the catalog web service
catalogSiteAgent.AuthorizationMode = AuthorizationMode.ThreadContext;
catalogSiteAgent.AuthorizationPolicyPath = AuthorizationPolicyPath;



//Inventory subsytem being ignored
catalogSiteAgent.IgnoreInventorySystem = true;

//configure the caching parameters
CacheConfiguration cacheConfiguration = new CacheConfiguration();
cacheConfiguration.CacheEnabled = true;

//Get the catalog context for the current site
CatalogContext catalogContext =
CatalogContext.Create(catalogSiteAgent, cacheConfiguration);

ProductCatalog cd = catalogContext.GetCatalog(CatalogName);

return cd;
}
catch (Exception ex)
{
throw (ex);
}
}

[/CODE]

SharePoint: Move Site Collection / Database Resizing

In SharePoint world, content databases can grow to huge numbers, which in-turn result in multiple (performance, archival, consolidation of Sites, etc...) issues. Solution is either to bring automation in place which is smart enough to allocate content db's for Sites, based on the mapped logical architecture or another way would be to re-size your content databases as per your needs on regular bases. I will not be talking on methods to bring automation in place, I'll leave that for some othe day. Today I will talk on how to resize your content db's using a simple stsadm approach fused with some XSL transformations.
To explaining in detail, let me layout a scenario I executed on my local vm's recently. Scenario executed was more of a POC for our production enviornment. I have a solution which contained nearly 200 site collections where few content databases were munning over 100GB's in size which is not recommended by Microsoft(http://technet.microsoft.com/en-us/library/cc298801.aspx). Also, there were other resons like, specific site collections which needed to be archived and backed up regularly where as some site collections needed to be backed up once in six months or so. All the site collections we categorised by defining multiple manage path(http://sharepoint.microsoft.com/blogs/zach/Lists/Posts/Post.aspx?ID=30). Lets name the managed paths:
1) Root :- /
2) Backup (Managed Path) :- /backup
3) Collaboration (Managed Path):- /collaboration
Let's name the databases as well:
1) WSS_Content_MyDB_1
2) WSS_Content_MyDB_2
3) WSS_Content_MyDB_3
4) WSS_Content_MyDB_4
Site collections were speard across and mixed up. Root site collection was mapped correct with WSS_Content_MyDB_1, but site connections under managed paths spread across all databases. Which made impossible to segregate content and define backup schedules based on logical categorization.
I used STSADM.EXE to help resolve the situation. Following are the steps:
1) Use following command to generate details of all sites in XML format:
==================================================
stsadm -o enumsites -url http://webapp_host_header > c:\sites.xml
==================================================
this command would generate xml as shown below:
[code]
<?xml version="1.0" encoding="UTF-8"?>
<Sites Count="7">

<Site Url="http://webapp_host_header" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_1" StorageUsedMB="118.6" StorageWarningMB="0" StorageMaxMB="0" />

<Site Url="http://webapp_host_header/Collaboration/site1" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_2" StorageUsedMB="0.5" StorageWarningMB="0" StorageMaxMB="0" />

<Site Url="http://webapp_host_header/Backup/site2" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_3" StorageUsedMB="0.5" StorageWarningMB="0" StorageMaxMB="0" />

<Site Url="http://webapp_host_header/Collaboration/site3" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_4" StorageUsedMB="0.5" StorageWarningMB="0" StorageMaxMB="0" />

<Site Url="http://webapp_host_header/Backup/site4" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_2" StorageUsedMB="0.5" StorageWarningMB="0" StorageMaxMB="0" />

<Site Url="http://webapp_host_header/Collaboration/site5" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_3" StorageUsedMB="0.5" StorageWarningMB="0" StorageMaxMB="0" />

<Site Url="http://webapp_host_header/Backup/site6" Owner="SANDEEP\srohilla" SecondaryOwner="SANDEEP\fadmin" ContentDatabase="WSS_Content_MyDB_4" StorageUsedMB="0.5" StorageWarningMB="0" StorageMaxMB="0" />

</Sites>
[/code]
With the help of following command we are going to move sitecollections to different database:

====================================
"stsadm -o mergecontentdbs -url http://webapp_host_header -sourcedatabasename WSS_Content_MyDB_3 -destinationdatabasename WSS_Content_MyDB_2 -operation 3 -filename c:\output.xml"
================================

There are couple things to note here:
1) Multiple Sites(I mean site collections) can be moved from one content database to another content database. Cannot moves sites from multiple DB's to one DB in one go. It hase to be 1 DB at a time.
2) c:\output.xml is generated from c:\sites.xml (created as explained above) by using XSLT. Take a look at the xslt code below:

[code]
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:strip-space elements="*"/>

<xsl:template match="Sites">
<xsl:copy><xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>

<xsl:template match="Site[@ContentDatabase='WSS_Content_MyDB_3']">
<xsl:if test="contains(@Url,'Collaboration')">
<xsl:copy>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
[/code]

STSADM - Object reference not set to an instance of an object

Its been nearly 2 days am struggling to deploy a wsp solution in my farm by not using system account credentials. Am running a small farm locally on my system comprising of DC, SQL, Indexer and WFE. It all started with a issue where I was not able to activate a feature on my site using System Account, as activating feature would trigger a functionality in the code where it will check the user and send out a mail after fetching the details from DC. Now you wont find "System Account" in your DC would ya....

NOTE : If you log on to MOSS as an account that is used anywhere else in MOSS say for example an application pool in IIS being used by MOSS then it instantly associates your logged on account as a System Account or in a case where your have gone to Central Administration > Application Management > Policy for Web Application (i.e. /_admin/policy.aspx) and checked the option
"Account operates as System"
by Editing user under seleted WebApp. "You should therefore create unique accounts for managing he Application pools and web applications and create accounts as MOSS administrators.

This meant I had to use a different account other than system account to achieve my objective. I created a new account (fadmin) in my DC and added it to Domain Admins. When I logged to Central Admin Box (i.e. Indexer) using fadmin credentials and tried to add wsp solution using STSADM it threw following error:

stsadm -o addsolution -filename testWSP.wsp
Object reference not set to an instance of an object.testWSP.wsp:
The Solution installation failed.

Now this just did not stop here,I began googling.... after reading some blogs it seemed that issue is related to access rights. I it drove me nutts when, even after giving Farm Admin rights to fadmin account it threw the same error.
I began comparing System Account (i.e. domain\srohilla) access privileges with fadmin access privledges.

Comes out System Account has access to SharePoint_AdminContent_<GUID> DB in SQL,where as fadmin did not. So went ahead and gave appropriate rights to fadmin. This did the trick. Yippeeee!!!!!!!!! Now am able to add solution files successfully via STSADM and activate features.

SharePoint: Version Table (Service Packs/Hot Fixes)

MOSS 20071 or WSS 3.0 SP2 + Cumulative update (June 09) 12.0.0. 6510

MOSS 20071 or WSS 3.0 SP2 + Cumulative update (April 09) 12.0.0. 6504
MOSS 20071 or WSS 3.0 SP2 12.0.0.6421
MOSS 20071 or WSS 3.0 Cumulative update (Feb 09) 12.0.0. 6341
MOSS 20071 or WSS 3.0 Cumulative update (Dec 08) 12.0.0. 6335

MOSS 2007¹ or WSS 3.0 Cumulative update (KB956056 & KB956057) 12.0.0.6327
MOSS 2007¹ or WSS 3.0 Infrastructure Update (KB951695 & KB951297) 12.0.0.6318
MOSS 2007¹ or WSS 3.0 post-SP1 hotfix (KB948945) 12.0.0.6303
MOSS 2007¹ or WSS 3.0 post-SP1 hotfix (KB941274) 12.0.0.6301
MOSS 2007¹ or WSS 3.0 post-SP1 hotfix (KB941422) 12.0.0.6300
MOSS 2007¹ or WSS 3.0 SP1 12.0.0.6219
MOSS 2007¹ or WSS 3.0 October public update 12.0.0.6039
MOSS 2007¹ or WSS 3.0 August 24, 2007 hotfix package 12.0.0.6036
MOSS 2007¹ or WSS 3.0 RTM 12.0.0.4518
MOSS 2007¹ or WSS 3.0 Beta 2 TR: 12.0.0.4407
MOSS 2007¹ or WSS 3.0 Beta 2: 12.0.0.4017
Office 12 (PDC image - pre-beta): 12.0.0.3111 (This version of Office does not have a support link in the Add/Remove programs dialog box).

Event ID : 6398 - WSS (IndexingScheduleJobDefinition - Access Denied)

It’s been three days I have been struggling with rectifying an insane error which keeps popping up in Windows Event Viewer under application category. I checked everything starting from permission settings on DCOM Component Services (OSearch) to recreating entire index and resetting all crawl rules and scopes, even creating new SSP. Steps as suggested in some Microsoft TechNet Posts are specified in my previous post, which did not help in full resolution of the issue. Following were the two errors which were giving me lot pain while setting up the environment. 

 Event ID 10016 and Event ID 6398

For resolution steps for Event 10016 click here.

Event ID 6398: Windows SharePoint Services 3    Error  Timer  6398   N/A   WIN2K3R2EE    "The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID b991a523-c9a3-402d-878c-31e7fa8b04b2) threw an exception. More information is included below.

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"

Root Cause Analysis:

Upon visiting following path: Central Administration > Operations > Timer Job Status I saw one of the job was failing each time. 

Indexing Schedule Manager on WIN2K3R2EE Failed 2/20/2009 6:00 PM  

Once Indexing Schedule Manager Timer Job was deactivated, alerts stopped coming. Upon reactivating, alerts appeared again. This seemed to be the culprit.

Next, I checked Central Administration > Operations > Services on Server > Windows SharePoint Services Search Service Settings where I found Service Account was running under predefined "Network Service".

Under service account comments it said: "The search service account must not be a built-in account in order to access the database. Examples of built-in accounts are Local Service and Network Service."

Final point to take note of it, error states it’s a Windows SharePoint Services 3 Timer Error. I went ahead WSS Timer Service at Start > Administrative Tools > Services

As one can see in the the above figure Windows SharePoint Service Timer is running as Network Service and error showed as "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"

Solution:

Following are the steps which helped me in resolving this issue.

1) Create new user account "X" (ensure accounts X have admin level privledges)

2) Associate account "X" with

i)  Central Administration > Operations > Services on Server > Windows SharePoint Services Search Service

ii )Start > Administrative Tools > Services > Windows SharePoint Service Timer

This did the trick. Am not seeing any 6398 alerts any more.

Cheers

Event ID 10016 and Event ID 6398

Recently, I am working on to build a SharePoint environment for my team. This is a brand new environment. So I created the AD accounts and did all those steps, account delegation stuff. Created the sites/site collections following our build docs. Everything was working out fine to a point where things started falling apart. I narrowed down the problem to following errors, which I dug up from windows application event viewer.

• Event ID 10016 : Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1}
• Event ID 6398: The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition

Solutions -

Event ID 10016 :

To prevent the event ID error messages from being logged in the System log, use the Component Services snap-in to enable the Local Activation permission to the IIS Wamreg Admin Service for the domain user account that you specified as the Windows SharePoint Services 3.0 service account. To do this, follow these steps:
1. Click Start, click Run, type dcomcnfg in the Open box, and then click OK.
2. Expand Component Services, expand Computers, expand My Computer, and then click DCOM Config.
3. Right-click IIS WAMREG admin Service, and then click Properties.
4. Click the Security tab.
5. Under Launch and Activation Permissions, click Edit.
6. In the Launch Permission dialog box, click Add.
7. In the Select Users, Computers, or Groups dialog box, type the domain user account that you specified as the Windows SharePoint Services 3.0 service account, click Check Names, and then click OK.
8. In the Permissions for UserName list, click to select the Allow check box that is next to Local Activation, and then click OK two times.

Event ID 6398: Still working on Solution (Following steps solved partial problem):

1. Open Start Menu > Administrative Tools > Component Services Tool
2. Drill Down and Expand DCOM Config
3. Navigate to the OSearch, Right Click Properties
4. Select the Security Tab
5. Add the Network Service Account to Local and Activation Permissions
6. Add the Network Service Account to Access Permissions
7. Restart the Office SharePoint Server Search Service from Start Menu > Administrative Tools > Services Tool
-------------------------------

I have found the solution to Error 6398. Please refer to my post here.