Development Matters Blog

SharePoint offers a very good object model which allows a developer to achieve just about anything. But what happens in situations when the developer must achieve certain functionality, but his or her code is not running on a server hosting SharePoint? That’s where the SharePoint Services step in.

Anyone who has tried to manage content in SharePoint using SharePoint Services knows that it can be a very challenging task. A lot of functionalities are limited, or don’t exist at all. Some of them are very basic and it can be a real mind cracker when it comes to the development of more complex functionalities. For example, there is no service that provides the method to delete a web site – a quite extraordinary fact, if I may add. Of course, the developer may develop a custom web service and use it for his or her purpose. However, sometimes a client requires the development of an application which is not allowed to add anything to the server machines. When that happens, the only tool left for the developer to use is the existing coding arsenal and his or her wit.

One of the very common and basic functionalities that may arise in the never ending list of client requirements is to develop a code which creates SharePoint sites. This should be rather easy, right? Well, not quite so. On this MSDN page you may see the list of all available web services. A web service websvcSites may appear tempting judging by its name, but it deals with the site content migration and site templates information. The websvcAdministration web service “provides methods for managing a deployment of Windows SharePoint Services, such as for creating or deleting sites”, as stated on the page. Unfortunately, by the term sites the documentation actually refers to site collections, thus our problem still remains unsolved.

The solution, believe it or not, lies in the web service called websvcMeetings. This service contains a class Meetings with a method CreateWorkspace. The purpose of this method is to create SharePoint meeting workspaces. It may seem odd to use such a method, because we are not actually trying to create a meeting workspace, but a site instead. The key lies in one of the method arguments – site template. By providing a site template other than the meeting workspace template, the method will create a corresponding site. This small trick extends the purpose of the method and solves the challenge of creating SharePoint sites using SharePoint web services.

The complete list of SharePoint’s default site templates can be found on this page. For custom templates, the developer should provide the name of the site template file which has been previously uploaded to the site collection’s site template gallery.

There are a few disadvantages with this method. For example, there is no option to set the permissions inheritance or whether the new site will contain the top navigation bar from its parent site. Actually, there are no SharePoint web services for the top navigation what so ever. This and many other disadvantages are eagerly expected to be implemented and enriched in the future releases of SharePoint platform.

A Few days ago, I tried to install Dynamics GP web services. I thought that all of the prerequisites were satisfied (OS, ISO, IIS, ASP, etc) but when installation started I got an error:

ADAM Error - Error Code: 20038.The wizard could not access the registry. Error code: 0×800706fd. The trust relationship between this workstation and the primary domain failed.

I found some info on Internet that one person noticed that this error occurs when installation is run on computer which is joined to a domain. That was all…

What I did next was assign the computer on WORKGROUP and log in as local admin. After starting installation everything was just great. Installation was finished successfully!

Then I went back to WS Install Admin Guide and found interesting content about ADAM.

ADAM or Active Directory Application Mode is required by the Dynamics Security Service. In order to install Dynamics GP Web Services, the current user must be in ADAM administrator role. The user who installed Windows Server 2003 (in my case local admin) automatically is in this role. But if we want to enable some other users to install, update or modify GP Web services we should add them in this role.

Note: ADAM is related to Windows Server 2003 and ADMSL (Active Directory Lightweight Directory Services) is related to Windows Server 2008 and we have same situation for both.

For more details see Appendix A: ADAM or ADLDS Administrators in WS Install Admin Guide. You can find it here.

In short notes, to add new user in ADAM Administrator Role, follow next steps:

• You must we logged as ADAM administrator.
• Open All Programs->ADAM.
• Create connection: Action-> Connect To and define connection string to server onto which GP Web services were installed. If the Web Services for Microsoft Dynamics GP installer has installed ADAM or the ADLDS instance, it will use the default port 389. If you’ve used a different port, specify that port value. Choose Configuration as the well-known naming context.
• Click OK to connect.
• Find ADAM installation and expand tree to find CN=Roles node.
• In the list of roles, select Administrators. Choose Properties from the Action menu to display the properties for the Administrators role.
• In the list of attributes for the Administrators role, locate and select “member”. Click Edit. The Multi-valued Distinguished Name with Security Principal Editor window will be displayed.
• Click Add Windows Account to specify the user to add as an administrator.
• Click OK to save your changes.
• Click OK to close the Administrator role properties window and close ADSI Editor.