Thursday, December 30, 2010

Local Service vs Network Service vs Local System Account


Local Service

The LocalService account is a predefined local account used by the service control manager.It has minimum privileges on the local computer and presents anonymous credentials on the network. Name of the account must be NT AUTHORITY\LocalService.

Network Service

The NetworkService account is a predefined local account used by the service control manager. It has minimum privileges on the local computer and acts as the computer on the network. A service that runs in the context of the NetworkService account presents the computer's credentials to remote servers. Network Service presents the machine credentials on the network, the remote token contains the "EveryOne" and "Authenticated User" group SIDs.

Local System

The LocalSystem account is a predefined local account used by the service control manager. It has extensive privileges on the local computer, Local System acts as the machine account on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. Localsystem is the most privileged account in a system, it's the only account that is able to access the security database (HKLM\Security). It's token contains the SID's of NT_AUTHORITY\SYSTEM and Builtin\Administrators.


Running a service as Local System is not recommended because it has powerful access to local resources, and Network Service should be used if possible.
A Local service running as Local System and Network Service behaves the same. It is because the local service running as Local System or Network Service is authenticated as machine account to remote services. Therefore, while Network Service is great for protecting local resources, it does not protect remote resources.



source: http://msdn.microsoft.com/en-us/library/ms686005(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms685981(v=VS.85).aspx

Thursday, December 23, 2010

SharePoint Architect Skill set

Infrastructure Level/Operational

1. Capacity Planning (Scalability)
2. Physical Architecture (Farm Setup, Network, OS, Licensing)

Application level (Functional and Non-Functional)

1. Knowledge of 3rd party webparts
2. Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
3. Techno-functional Mapping of requirements
4. Information Architecture
5. Logical Architecture
6. Conceptual Architecture
7. Detailed Design
8. Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
9. Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.
10. Read SharePoint code using reflector


Deployment

1. Best way to go for deployment, first time and incremental

Migration

2. SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007).

Others

1. collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).
2. Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).
3. Interacting with Enterprise Architect groups if any.
4. Have at least 5 SharePoint blogs
5. Attend local SharePoint usergroups

Reference:
1. http://blog.furuknap.net/the-role-of-a-sharepoint-architect
2. http://blogs.msdn.com/b/joelo/archive/2007/07/23/depth-and-breadth-in-a-sharepoint-architect-skills.aspx

Software Development Process

Requirements Analysis

Get the requirements from the client/customer. Make sure you identify incomplete, ambiguous or contradictory requirements.

Refer: http://en.wikipedia.org/wiki/Requirements_analysis

Specification

Specification is the task of precisely describing the software to be written. Specifications are most important for external interfaces that must remain stable.

Refer: http://en.wikipedia.org/wiki/Software_requirements_specification

1 Table of contents

1.1 Introduction

1.1.1 Purpose
1.1.2 Scope
1.1.3 Definitions, acronyms, and abbreviations
1.1.4 References
1.1.5 Overview

1.2 Overall description

1.2.1 Product perspective
1.2.2 Product functions
1.2.3 User characteristics
1.2.4 Constraints
1.2.5 Assumptions and dependencies

1.3 Specific requirements

1.3.1 External interfaces

1.3.1.1 User interfaces
1.3.1.2 Hardware interfaces
1.3.1.3 Software interfaces
1.3.1.4 Communication interfaces

1.3.2 Functional requirements
1.3.3 Performance requirements
1.3.4 Design constraints
1.3.5 Reliability
1.3.6 Availability
1.3.7 Security
1.3.8 Portability

1.4 Appendixes


Software architecture

The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed.
Refer: http://msdn.microsoft.com/en-us/library/ee658098.aspx
http://msdn.microsoft.com/en-us/library/ee658084.aspx

Design

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.


Implementation

The purpose of programming is to create a program that exhibits a certain desired behaviour. The process of writing source code often requires expertise in many different subjects, including knowledge of the application domain, specialized algorithms and formal logic.Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.


Testing

Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.


Documentation

An important task is documenting the internal design of software for the purpose of future maintenance and enhancement.

Deployment

Deployment is all of the activities that make a software system available for use. The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both.
Refer: http://en.wikipedia.org/wiki/Software_deployment

Maintenance

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About 60% of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work.

Refer: http://en.wikipedia.org/wiki/Software_maintenance