Saturday, July 28, 2012

Windows Azure Overview has all the required software to start developing against Windows Azure. It is more developer focussed, eliminating various infrastructure details thereby enabling developers to focus more on application development.

Deployments and storage functionality can be tested by developers on local machines using Azure emulators before publishing on Azure

Deployment can be done using,
- Azure management console (web version)
- Visual studio publsh project
- Powershell

All deployments are automated by Azure using the configurations and solution packages provided by developers. Data centers at geographically significant locations, network setup, load balancing, failover storage are all provided by default to all azure applications. Based on subscriptions and configurations provided by developers Azure automatically builds required infrastructure and deploys custom solutions.

Solution package updates can be done in 2 ways:
- In place : Developers publishes updated solution package to Azure. It then takes one server at a time out of rotation from the NLB, applies the solution package and add the server back.
- Branching : Create a staging branch which will have similar vms as the production setup. It will have a private vip and dns. Developers will prepare the staging branch to what is required on production and once ready we just "Swap VIPs" between production and staging as both branches are similar.
Building blocks: Ready to use functionality already built into Windows Azure. All building blocks fundamentally make use of redundancy and failover.
- Storage : BLOB, SQL Azure, Table storage (NoSQL)
BLOB : 3 drives write for each write operation. Geo redundancy between data centers (built-in feature), file system on cloud, can be exposed on http,

Storage Account: Include a public url to allow access over http, choose a region local to where the code will be deployed, primay access key (used to program against it)
Use cloud explorer to manage Blob storage from desktop:
The blob storage is fully accessible using API from code.

SQL Azure:
Relational db in the cloud
patching, clustering and backups are all included and managed by Azure

Table storage: non-relational tables

Messaging using Service Bus Queue: Design loosely coupled architectures.  Rather than the FE depending on synchronous callbacks from BE use Queues to store FE requests and then have BE process the queue items asynchronously. Add more resiliency.

The above point can be easily thought through using a order management system, A FE system pushing orders into a queue and a BE system processing them. Add more processing power to FE or BE as required using Azure.

Hybrid systems:
The FE system in the above example could be website hosted in Azure which accepts messages into a Service Bus Queue
the BE could be a console app running on-premise listening and closing to the messages on Azure.

Systems Center could be used to manage on-premise and cloud infrastructure.

Service Bus Relay: Let me explain this with the below e.g.
You have an on-premise database. If you need to expose this database to mobile users via a cloud app then one the ways you can do it with very less code is by using service bus relay which connects Azure to the on-premise database using WCF endpoints and then presenting the information out to the mobile user. As you can see this is a synchronous operation.



Friday, July 27, 2012

SharePoint 2010 SharePoint Administration Service not starting

SharePoint 2010 SharePoint Administration Service (spadminv4) not starting.

This is because of a new security patch that requires access to the internet from the server which in many cases is not available. For those servers the SPAdminv4 service times out while trying to start.


- Enable internet connectivity from the affected servers via TMG
- Uninstall the patch after checking with security.

Monday, July 16, 2012

SP2010 Fast Search

FAST Overview and Planning:

Compare SharePoint search products:

Index connectors:
The FAST Search connector crawls:
- SharePoint sites
- Web sites
- File shares that contain content such as Microsoft Office documents
- Exchange public folders
- Line of business data, for example content from databases
- Custom repositories, accessed with a custom built connector

A content source in the FAST Search Content Search Service Application (Content SSA) is a set of options that you can use to specify what kind of content is crawled, what URLs to crawl, and how deep and when to crawl.

You can create up to 500 content sources in the Content SSA, and each content source can contain as many as 500 start addresses.
You can only crawl one kind of content per content source.

Custom indexing connector:

Before you can start incremental crawls of one or more content sources, the system must first complete a full crawl.

Federation (Type of connections)
Search index on this server
FAST Search index.
OpenSearch 1.0 or 1.1

The content access account that you use must have read permissions on all content that is crawled

FAST Search Web crawler
The FAST Search Web crawler is typically a component inside a FAST Search Server 2010 for SharePoint installation. Internally, the FAST Search Web crawler is organized as a collection of processes and logical entities, which in most cases run on a single server. When the number of Web sites or total number of pages to be crawled is large, the FAST Search Web crawler can be scaled up by distributing these processes across multiple hosts. This requires additional configuration. It can crawl HTTP, HTTPS and FTP content and supports NTLM version 1 (and to a limited extend version 2), Digest, basic auth and form based logon authentication. RSS scheduling is supported and you can tag linked documents from the feed.

FAST Deep dive videos:

Deployment steps: wizard fails) to connect, cert issue) (enable queries) (verification) (no results issue)

Configure Authorization:
If Get-FASTSearchSecurityClaimsUserStore does not return anything then configure below steps,
1. From the FAST Search Server 2010 for SharePoint, open a Microsoft FAST Search Server 2010 for SharePoint shell under the user account of a user who is a member of the local FASTSearchAdministrators group and run the following commands.
New-FASTSearchSecurityClaimsUserStore -id win
Set-FASTSearchSecurityDefaultUserStore -DefaultUserStoreId win
2. Repeat step 1 on each query server.

If you added the fast admin account to the local admin group on the server, please remove it. It should only be a part of the FASTServerAdministrators group on the server.
Remember the behavior mentioned in the above link will exist if you try to query fast locally (using http://localhost:13280) or from SharePoint using an account that is added to the administrators group on the FAST server.

Other references:
Availability / Fault Tolerance

Friday, July 6, 2012

SP2010 Claims

WS-Security provides a core function by defining mechanisms for assuring message authenticity, integrity and confidentiality through the use of security tokens

WS-SecurityPolicy enables the description of the security requirements of services via assertions about the security mechanisms of the services (i.e. algorithms and types of tokens that the service accepts). Using these assertions web services are able to recognize and assess the types of security tokens and claims that are required for exchanging messages securely. 

WS-Trust provides an additional piece of the foundation for federation by defining a service model, the Security Token Service (STS), and a protocol for requesting/issuing these security tokens which are used by WS-Security and described by WS-SecurityPolicy.

A fundamental goal of WS-Federation is to simplify the development of federated services through cross-realm communication and management of Federation Services by re-using the WS-Trust Security Token Service model and protocol.
WS-Federation does not restrict users to a specific security token format. Instead, WS-Federation builds on the WS-Trust encapsulation mechanism, the RST/RSTR, which allows protocol processing to remain agnostic of the type of token being transmitted.

Access to SharePoint Server running in Claims Mode Authentication utilizes
a Security Token Service (STS) which is essentially an authentication gateway to SharePoint
Server that enables access for Windows Integrated Authentication, Form Based Authentication and Trusted Claims Providers (TRUST).


Some service applications require the use of the Windows Identity Foundation (WIF) Claims-to Windows Token Service (C2WTS) to translate claims within the farm to Windows credentials for outbound authentication. It is important to understand that Service Applications that come with SharePoint Server can leverage the C2WTS only if the incoming authentication method is either Classic mode or Windows claims. 

Claims Augementation

A claims provider in SharePoint Server 2010 can be used to augment claims and provide name resolution. By using claims authentication, you can assign rights based on claims without having to know who users are, or how they are authenticated. You only have to know the attributes of the users. You can, for example, use a piece of corporate metadata that is associated with a person and have the claims provider do a lookup to another system to determine the different identities of a particular person—Windows, forms-based authentication, SAP, CRM, and so on—and map another identifier or set of claims to that identity. Those claims are then used to grant access to resources.

Compund Claims augemenation with AND operator

Claims encoding

Difference between Windows Claims and SAML Claims

Network load balancer considerations

You need to set network load balancing to single affinity when using claims-based authentication. If you use SAML token-based authentication with AD FS on a SharePoint Server 2010 farm that has multiple Web servers in a load-balanced configuration, there will be an effect on the performance and functionality of client Web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Server 2010 for each permission-restricted page element. If the load-balanced solution is not using affinity, each secured element is authenticated to more than one SharePoint Server 2010 server, which will result in rejection of the token. After the token is rejected, SharePoint Server 2010 redirects the client to authenticate again back to the AD FS server. After this occurs, an AD FS server will reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service attack. If performance is adversely affected or pages do not load completely, set network load balancing to single affinity. This isolates the requests for SAML tokens to a single Web server.