Development: Troubleshoot your #SharePoint custom Web services

When I first read the W3C definition of a Web service back at university, I admit that it made little sense to me:

"a software system designed to support interoperable machine-to-machine interaction over a network...using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards".

How does one go about writing "SOAP-messages"? Would I have to serialise the XML myself? It all sounded rather daunting and, like most other students I settled for memorising the definition and a few benefits of using Web services.

However, having been employed as a SharePoint administrator come developer for some time now, I am pleased to say that writing a Web service, even one that is to be used in the context of WSS isn't all that difficult. As with most developments tasks that are worth doing (this one certainly is), there are numerous hoops that must be jumped through, most of which are documented in the Microsoft articles below. Note that bar editing a few XML statements so as to account for SharePoint virtualising its URLs (a lot simpler than it sounds - just follow the instructions), there is no need to get your hands dirty with serialization or SOAP (that's impossible with soap anyway, right?)

http://msdn.microsoft.com/en-us/library/ms464040.aspx (MOSS)

http://msdn.microsoft.com/en-us/library/ms464040(office.14).aspx (SP2010)

OK, so Web services that operate in the context of SharePoint foundation are not new. There are numerous tutorials available online that are very helpful such as Creating a Custom Web Service for SharePoint.

However, having spent a few frustrating hours with a number of recurring Web service issues, I thought it would be worthwhile sharing them with the world (or at least those that read this blog). If you are having issues deploying or consuming a custom Web service, I recommend you ask yourself the following questions:

Ask yourself

• Have you created ASPX pages for the .disco and .wsdl files with syntactically correct virtualised URLs?
• Is the updated Web service DLL in each SharePoint WFE GAC?
• If relevant, is the updated Web service DDL in your SharePoint Web application bin folder with correct NTFS permissions?
• Are the new DISCO, WSDL and ASMX files in the ISAPI folder with correct NTFS permissions?
• Can you browse the web service at https://application.domain.com/_vti_bin/webservicename.asmx?
• Does the Web service work as a console application?
• Are your custom application settings (e.g. web.config) settings correct?
• Is the problem really because of your Web service?

Note that although these common issues are based on my experiences with MOSS, I have taken a quick look through the 2010 walkthrough and there doesn't appear to be a lot of difference between the two processes. Please let me know if you have encountered a "common issue" that I haven't listed (MOSS or SP2010).

Good luck! I hope you enjoy consuming your new custom SharePoint Web service and the benefits that go with it. That includes code re-use, versatility and interoperability which hopefully leads to some form of cost saving for you and your organisation.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Administration: do you know your DR process?

"This computer can't connect to the remote computer" is a verbose error message that us server administrators dread seeing when we connect to a server farm via RDP. A typical reaction would be to blame the local Internet connection (which in my case is a certain privatised former state telecommunications operator that will remain anonymous). Most of the time, we will try to access a site that is known to be "reliable" to confirm this is the case - I normally use Gmail. However, what would YOU do if Gmail was accessible and your server(s) wasn't?

As I have an unusually busy weekend ahead of me I thought I would quickly share with you a recent experience of mine and the various "what if" questions that sprang to mind.

It was a late night in the office and the sysadmin team was busy deploying the most recent batch of MS security patches to our farm. Notifications had been sent to our client base warning them of downtime so I wasn't too concerned when I witnessed the error above when I attempted to RDP to one of our ISA server boxes.

However, minutes quickly turned to an hour and the command prompt window I had opened to ping the server ("ping fqdn -t") was still returning timeouts. I knew something was amiss and, after confirming with the rest of the team it soon became obvious that the server in question had hung during a compulsory reboot following deployment of MS security patches.

A few queries crossed my mind at this point that made me realise that our DR process was more than a little ambiguous:

Ask yourself

• What number would you use to contact your data centre? Where is it documented (and would it be available in a disaster...)?
• When would you "sound the alarm" and notify other members of staff? Who would you escalate the issue to internally? What if they weren't available?
• At what point would you notify clients of the service disruption?
• What kind of authorisation would be required at the datacentre to approve a hard reset if this was necessary, and would the relevant individuals within your organisation be available?
• Would you have available hardware resource to rebuild a server at a moments notice if necessary?
• Are there any virtual environments available as a temporary resolution?
• Are software and backups readily available to allow a new server to be rapidly provisioned?

As it happened, I was very lucky. In the absence of a clearly defined process, I decided to call our data centre right away to clarify what would be required to obtain access to the server farm if necessary. They informed me that a phone call to one of our "authorised contacts" would be sufficient for them to reboot the server themselves, which just so happened to resolve the issue.

I still haven't had a chance to identify the root cause of the issue, but the lessons that I learnt from this experience that I hope will be of use to you are as follows:

• Ensure all contact details are thoroughly documented for both internal and external escalations. This includes the order in which contacts should be called and (ideally) a minimum of two phone numbers for each contact
• Ensure escalation and notification times are clearly specified so remove ambiguity. In this context, a "gut feeling" probably isn't clear enough.
• Ensure the correct process for obtaining appropriate security clearance is documented and that staff are made aware of said process.
• Ensure sufficient resources (hardware, software, people) are available to deal with a crisis, especially where the nature of your service depends on high availability.

Ideally, all of this information should be documented already as part of a more general DR strategy but I would certainly recommend you ask yourself a few basic "what if" questions with regard to disaster and see if you are prepared.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites

Security: Preparing your SharePoint farm for a corporate security review (part 2 - Auditing)

The words "security review" in the context of IT can mean different things to different organisations. For large organisations seeking to outsource an IT function to a third party hosting provider it could be simply a necessary formality; a series of hoops that must be jumped through in order to reassure users that the third party solution is secure. Secure in this context typically means that the risk of the service availability, integrity and confidentiality being impacted is no more than is usual for solutions of a similar nature.

However, for smaller organisations with fewer resources, it can sometimes result in a mixture of fear and anxiety due to the consequences of failing said review. After all, who would trust their sensitive data to a hosting provider that has not been found worthy of a security stamp of approval?

The concerns raised over a security review can be minimised by ensuring your organisation has prepared itself effectively. In preparing ourselves, we typically start by reviewing a list of "frequently asked queries" that most organisations send us as a part of their security review. This weeks category is Auditing (part one on Access Controls is available here):

Please note that the views expressed herein are my personal views and are not intended to reflect the views of my employer at the time of writing.

2. Auditing

• Q. Will common actions (e.g. accessing and editing documents) be audited?
• A. Clients like the ability to audit access to their information - ensure there is minimal impact to performance and enable it (IIS, SharePoint, Web Proxy logs).

This sounds like an obvious one but in my experience it is often missed when deploying SharePoint sites. MOSS itself has a number of different auditing options, and although to my knowledge there are no built in retention settings they do provide a fairly detailed means of auditing actions within SharePoint. A range of different events can be audited from basic actions such as opening documents to slightly more obscure events such as searching site content. I wont go into any detail here about how to go about configuring these settings in MOSS as Bill English has already provided a nice post on his blog.

I have heard rumours that SharePoint 2010 will include retention settings as well as the current settings provided by MOSS - please let me know if you know somewhere that confirms this.

Aside from SharePoint, I would also recommend you enable IIS logging (log to somewhere other than the OS drive to prevent unnecessary disk usage) and Web proxy logging (e.g. ISA Server) where applicable. In our case, we set ISA server to log to file rather than a SQL DB for consistency with the IIS logs.

• Q. How, and how often are the log files checked?
• A. Weekly is typically sufficient but this may need to be more frequent depending on the nature of your service. In particular, check SharePoint access and AD audit logs.

Manually checking logs for security breaches is a necessary (albeit dull) part of maintaining a secure hosted service. A diligent server administrator should implement a range of processes to minimise the chances of a security breach going unnoticed depending on the nature of the service offering. In the context of a SharePoint site, I would recommend that access logs (that is, SharePoint audit logs and IIS logs) are compared to your ACLs. For IIS, I would recommend you use a tool such as Log Parser; for SharePoint I would start with the built in site collection usage reports and analyse the more detailed audit reports on a less frequent (e.g. fortnightly) basis.

You should also consider checking your AD logs (Windows "Security" logs on your domain controllers) on a regular basis as a part of your audit process.

• Q. Are server log files read only?
• A. Set all log files to read only to improve log credibility. Consider moving old logs to another server to prevent tampering.

Setting log files to be read only is an essential step toward maintaining credible log files.

Obviously someone in the organisation must retain write access to the logs but this risk can be mitigated by implementing SoD and preventing those individuals from having write access to the relevant sites (as opposed to site logs) in question. In smaller organisations, it may be easier to simply grant write access only to a very small number of individuals - perhaps those in the upper echelons of management (I'll let you decide if that's a good idea).

Mark Burnett wrote a good post on this back in 2002 (here) that I recommend you refer to for a more detailed explanation.

• Q. Are failure and success logon attempts logged?
• A. Consider enabling failure and success auditing based on your disk space and log retention requirements.

This seems to be another common query. In preparing for a corporate security review I would recommend you review your current log space requirements and (if you haven't already) consider enabling both failure and success auditing. I mention disk space because enabling failure and success auditing can rapidly fill a log for a large site and may not be feasible where storage is limited. This risk is further increased by the chances of a DoS attack which would result in a large number of failure audits in quick succession (see this MS article for more information).

A workaround for this problem is to enable log overwrites and limit the size of the event log based on current size and log retention requirements. For financial systems (e.g. banks) this option is typically not viable given that there are typically legal requirements to retain logs for a fixed duration of time. However, for Web applications that are of a less sensitive nature (that are not subject to the same legal restrictions) you may want to consider this as an option.

• Q. Are logs backed up?
• A. Ensure all logs are backed up and secured in a separate location to your Web server(s).

Again, this is something I typically get asked by financial organisations due to their understandably stringent security requirements. Whether your clients have asked for this or not, however, I would recommend you implement a log backup process that meets your retention requirements. If logging to a file (e.g. IIS), this can easily be achieved by adding the log directory to your regular NTBackup routine.

When backing up logs, ensure that the logs are shipped to a location that is physically separate from your Web servers. This is useful from both a log integrity and DR perspective - if a security breach occurs on your Web server and there is a risk that the logs have somehow been tampered with (have you set them to be read only?), you have a second copy for verification. If your Web servers suffer a hardware failure, you still have log backups to meet any legal requirements that may be imposed on your service.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites