Tuesday, April 26, 2011

AD Admin Roles & Responsibilities

 
Function
Roles & Responsibilities
AD advisory committee
ADAC serves as an advisory committee to the Information Technology Division by providing critical user input regarding the operation of Berkeley Lab’s Microsoft Active Directory service.
ADAC members are specifically chartered by the Information Technology Division to provide advice and feedback on plans regarding the operation and configuration of MS Active Directory.
Specific Responsibilities:
    Advise IT division about the policies and procedures governing the use of Microsoft Active Directory (MSAD) services at LBNL
    Provide Feedback concerning requirements for new capabilities and changes in existing services
Frequency of Meetings
  • ADAC members meet quarterly to review MS Active Directory operations at the Lab and provide input on configuration and policy issues
  • Special meetings can be requested by any member if time sensitive issues need to be addressed.
Membership
ADAC will be composed of seven members
  • A chair appointed by the Berkeley Lab CIO. 
  • Three members from the IT division representing staff that manage AD and set cyber security policy
  • Three members representing scientific and operations organizations at LBNL.
Domain Administrators
Domain Administrators at LBL on occasion have to perform duties associated with Schema and Enterprise administrators as identified below.
Schema Administrator
    Maintains security and integrity of schema Oversees modifications to schema
    Full disaster recovery plan and practice of schema
Enterprise Administrator
    Creation and management of the forest Overall security and reliability of the forest Creation and removal of domains Management of trust relationship with test and ALS domains
    Full disaster recovery plan and practice of trusts
Domain Administrator
    Creation and management of directory infrastructure
    • Includes FSMO roles, trusts, Kerberos KDCs, replication topology, etc.
    • Creation of all top-level OU hierarchies with subOUs, groups, and appropriate security permissions.  This includes adding the OU Admins to the AddComputers group, Group Policy Creator Owners group, and OU Admins mail list. It also includes setting appropriate permissions on the created objects
    Monitor and reporting associated with the reliability and security of the domain
    • Use the domain admin account only for actions that require the privilege level of this account
    • Monitoring changes to domain root and domain controllers OU to ensure unauthorized changes do not occur
    • Day-to-day management of domain controllers
    • Monitoring connectivity, synchronization, replication, netlogon, time services, FSMO roles, schema, NTDS database partitions, DNS settings, SRV records, and trust relationships
    • Review DC event and security logs and take corrective actions
    • Monitor and resolve security situations at all levels of domain to ensure stable and secure domain
    Domain Controller Management
    • Physical security of the domain controllers in IT Division space and oversite for all domain controllers
    • Backups and restores on domain controllers
    • Full disaster recovery plan and practice of DCs and core Directory objects
    Policy monitoring and compliance
    • Apply and enforce LBL standard naming conventions for objects in the domain
    • Comply with LBL AD Change and Configuration Management (CCM) requirements
    • Comply with LBL AD policies and standards as defined on the AD Web Site
    • Monitor compliance with LBL AD policies and standards as defined on the AD Web Site, including change management
    • Verify LBL AD Change and Configuration Management (CCM) requirements are implemented by OU Administrators
    Communication and coordination
    • Arbitrate disputes between OU Admins
    • Provide OU Admins assistance when requested
    • Participate in ADAC
    • Coordination with CPP to ensure the LBL domain is secure
    • Comply with all CPPM orders regarding emergency conditions
    • Coordinate with Institutional Services to help them implement SSO, metadirectory, and other IS initiatives
    • Coordinate the use of the test domain by OU admins and others that need to model processes before they are deployed to the production LBL domain
    • Participate in OU Admin meetings as needed
    • Work collectively with the OU administrators
    Secure remote administration of the DCs and member servers managed by the Infrastructure Group Manage group policy at root of domain and for Domain Controllers OU Creation, testing, and management of GPOs intended to be used by multiple OU Admins Manage the Users and Computers Containers Install and manage security reporting tools used to monitor changes to the Active Directory Delegate monitored data and elevated privileges to others as needed Create and maintain the test domain as a reasonable approximation of the production domain Coordinate and configure alarm distribution to OU Admins for OU-related events Plan and manage all migrations and upgrades related to the AD or the DCs Verify new software deployments and GPO policies work by testing them in the Primus test domain as appropriate
OU Administrators
    Ensure overall security and integrity of their managed OU hierarchy
    • Use the OU admin account only for actions that require the privilege level of this account
    • Monitoring changes to OU hierarchy to ensure unauthorized changes do not occur
    • Delegation of authority to others for appropriate object administration in their OU hierarchy
    Account management
    • Creation/deletion/management of objects, i.e. local user accounts, groups, workstations, servers, printers, etc. in their OU hierarchy
    • Regularly perform housekeeping duties to keep OU hierarchy clear of stale, unused, expired, and objects no longer needed
    • Process requests for access control authorized by data owner
    • Process requests for group drive mappings via login script
    • Create new computer accounts and join to directory services
    The OU administrator will designate which administrators have "account operator" access to the Windows user accounts for users in their department.
    • These account operators will have privileges that let them make changes to a subset of attributes for the accounts in their OU
    • This subset of attributes includes Windows-centric information like home directory location, profile location, terminal server settings and other kinds of user data that isn’t replicated from the root of the LBL domain
    Group Policy Object (GPO) administration, troubleshooting, and management Publishing resource objects from their OU hierarchy in the Active Directory as applicable Manage Group Policy Object (GPO) links in OU hierarchy Coordinate activities of Member Server owners
    • Monitor department/member server(s) performance and event logs for all member servers in their OU hierarchy not maintained by Computing Infrastructure Group (CIG)
    • Work with server and/or data owners to set up permissions
    Policy Compliance
    • Comply with LBL AD policies and standards as defined on the AD Web Site
    • Comply with LBL AD Change and Configuration Management (CCM) requirements
    • Apply LBL standard naming conventions to objects in their OU hierarchy
    Contact information.
    • Each top-level OU must contain contact information for the department to facilitate contacting OU administrators
    • When OU manager changes, notify the Enterprise Administrator
    Verify new software deployments and GPO policies work by testing them in the Primus test domain as appropriate. Communication and coordination
    • Work collectively with the domain admins and with other OU administrators
    • Keep informed about domain-wide changes (e.g. attend periodic meetings of the OU administrators or participate in mail lists)
    • Provide the following to the domain admins, when suspecting a desktop related problem stems from a change to the Active Directory or DC configuration
      1. event description
      2. logon name of affected user
      3. name of affected computer
      4. time of event
      5. relevant warnings and errors in event logs
      6. relevant warnings or errors displayed on screen
Server Owners (maybe dual role with OU administrator)
    Host and maintain server (i.e., IIS, business specific service, etc.) Patching/software upgrades Volume/partition space management Hardware migration Software licenses for all member server(s) added to their OU hierarchy hardware maintenance for all non-Infrastructure-managed member servers Operating system maintenance for all non-Infrastructure-managed member servers Maintain level of member server system security by applying Service Packs and security patches Department application, file service, workstation and printer support Create printer objects and access control lists. Backup/recovery Full disaster recovery plan and practice
Desktop Support
    Request drive mapping via login script when needed from OU manager Add user domain account to workstation Assist data owners with archiving to offline storage (dvd/cd) Provide the following (if possible) to the domain admins, when suspecting a desktop related problem stems from a change to the Active Directory or DC configuration
    1. event description
    2. logon name of affected user
    3. name of affected computer
    4. time of event
    5. relevant warnings and errors in event logs
    6. relevant warnings or errors displayed on screen
Data Owners
    Request workspace from OU manager Setup data access control lists with OU manager Provide space usage projections to OU manager Maintain house keeping & periodic data cleanup Request drive mapping via login script when needed from OU manager
Help Desk
    Create new user accounts Disable user accounts for xstaff (Remove Password) Password reset service Creating and routing of tickets related to Active Directory issues
End userUsers who experience problems with a particular service should contact the IT Help desk for general questions.

If the issue can’t be resolved, then the Help Desk (or the End user) can contact the OU administrator

Wednesday, March 9, 2011

Common issues seen in Exchange 2007 migrations to Exchange 2010


Common issues seen in Exchange 2007 migrations to Exchange 2010

  • Strange errors may appear during OWA/Outlook Anywhere, Offline Address book management (e.g. Event ID 9519 "Error 0x80004005" in the application event log, etc.).
  • Event ID 9519 "Error 0x80004005" is logged in the Application log when you try to mount a database in Exchange Server 2010 or in Exchange Server 2007
    • In rare situations, you may need to apply the solution from the link above, to “Exchange Enterprise Servers” group (e.g. Give the group the user right to”Manage auditing and security log” in the domain controllers GPO) – I saw this issue when the original Exchange 2007 server was installed on a domain controller!
  • After creating a new Exchange 2010 database, the new database will not mount and the following error may appear in the application log: “Active Directory operation failed on <<Name of DC>>. This error is not retrievable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1: 0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB)”
  • You cannot create a new Exchange Server 2010 Mailbox database in a multiple domain environment
  • This issue also appears in customer environments with only a single domain, so if you see this I recommended you review the steps below;
      • Use the following options when creating a new Exchange 2010 database:
        • Create a new Exchange 2010 database without mounting it. Allow for AD replication. If DB will still not mount, continue with the next steps;
  • Use powershell to force the Exchange 2010 to use a preferred local domain controller: "Set-ADServerSettings –PreferredServer "mydomaincontrollername.domainname.local"
  • Mount the database by using the following powershell command: "Mount-Database -Identity "Second Mailbox Store" -DomainController mydomaincontrollername.domainname.local"

Monday, March 7, 2011

DATA Storage


NAS (Networked Data Storage)

Separating storage from the server reduces the file serving activity and I/O bottlenecks and increases server bandwidth. CPU cycles can then be dedicated to handling application requests, resulting in improved client response time.
There are three major technologies:
  • iSCSI (Internet SCSI) commands over the Internet
  • NAS (Network Attached Storage) serving files
  • SAN (Storage Area Network) on separate network fabric
  • Combination's of the above

iSCSI (Internet SCSI)

The iSCSI (Internet SCSI) RFC 2026 at draft 20 completed in February 2003 specifies how to run SCSI commands over TCP/IP, providing a lower cost alternative for storage area networking, using cards from:
  • QLogic SANblade[tm] 4000 Series
  • Intel PRO/1000 T IP Storage Adapter
  • Emulex GN9000/SI(VI) 1Gb/s iSCSI Host Bus Adapters
  • Adapter ASA-7211 iSCSI HBA
iSCSI IETF RFC 3720 introduces complete error recovery mechanisms called Error Recovery Level Two (ERL 2)
In any SCSI connection there is at least one initiator and one target.
Initiators are the devices which request, or initiate, any SCSI communications. They request data writes, reads and any other SCSI operations. Usually initiator is the HBA in the computer which is using SCSI disks, tapes and other target devices.
Targets are the devices which perform SCSI commands at a request from initiators, but never initiate SCSI activity. Examples of SCSI targets are: disks, tapes, RAID arrays, robotic libraries and many more.

Network Attached Storage (NAS)

NAS filers are special-purpose file servers (i.e., "appliances") that attach to a local area network (LAN) to deliver files to client systems - or other servers acting as clients - via TCP/IP within a LAN.
NAS filers are sometimes called NAS "heads" because the NAS "node" is referenced using the IP address of the head device.
Most NAS supports Multi-platform File Sharing by simultaneously supporting Windows Common Internet File System (CIFS) and Unix Network File System (NFS) as well as file systems associated with Macintosh, Novell, and other operating systems. This makes them ideal for sharing files across OS platforms on the same network.
CIFS was formerly known as Server Message Block (SMB) developed by IBM and Microsoft to support file sharing in DOS. This protocol is used today in UNIX systems as part of the Samba open-source utility package.
Many NAS systems also support HTTP so that clients can download files and administer the system using their Web browser.
Since NAS filers do not need a general-purpose operating system, they cost less, have less to go wrong. They also have less avenues of attack, which make them more secure than file servers.
Some NAS systems can expand into multiple terabytes. Non-scaling NAS systems need to be taken offline to redistribute data when adding capacity.

Storage Area Network (SAN) Storage

Due to the high-speed (1 to 2Gb/s data transfer rates in 2006, and 10Gg/s in 2008), SANs usually run though a fiber channel (IEEE 802.2) networking equipment.
At the fabric layer, fibre technology provides sophisticated cascading switches, switch initialization, and zoning.
It is almost a mute point to compare the total costs of a SAN, since in may large/enterprise shops that need highly-available central consolidated data store for clusters of servers to access, it has become a "must-have" for its ability to handle large amounts of data quickly and securely at low per-byte hardware, power, and manpower cost.
Fiber comes with advanced services such as
  • Fabric Login (FLOGI) Enables nodes to be successfully initialized (allocated a unique address) in a switched environment, enabling communication between two nodes
  • Simple Name Server (SNS) Helps a source node to discover the destination node within the fabric without causing unnecessary communication overhead
  • Registered State Change Notification (RSCN) that notifies Fibre Channel nodes about the changes in the existing topology
Fibre Channel technology are used on trans-oceanic cables (which have repeaters every 10km, powered by a copper sheath around the fiber.) But the HBA and devices can be up to 500m apart.
A series of standards from the American National Standards Institute (ANSI) defines 3 main topologies:
  • point-to-point, where devices are directly connected to each other (without the use of hubs, switches, or routers). Transmissions are sychronous (cannot transmit and receive, simultaneously).
  • Fibre Channel Arbitrated Loop (FC-AL), which shares bandwidth with up to 126 nodes on a distributed uni-directional ring topology, connects with hubs — the simplest form of a fabric topology.
  • Fibre Channel Switched Fabric (FC-SW) provides nondisruptive scalability and switch connection among up to 16 million nodes — the highest performance and connectivity topology.
Transmits data in frames of 2148 bytes maximum.

Tuesday, March 1, 2011

Exchange server 2010 installation using command line




Step by Step
1. Prepare your forest and organization in Active Directory
First you need to do the Schema preparation. Since this is a fresh new setup in the lab, I will perform the preparation on domain controller



Run Setup from the directory where your Exchange 2010 installation files are located. Here is the cmdlets
Setup /PrepareSchema or Setup /ps
*If you are running the prep process on the computer which is member of the forest or domain, and the OS is Windows Server 2008, you need to install the following component before executing the prep.
ServerManagerCmd -i RSAT-ADDS
Below screen capture shows that its completed.



Next, you will need to prep the domain and organization. Here is the cmdlet
Setup /p /on:SG or Setup /PrepareAD /OrganizationName:SG (where SG is my organization name in the Lab)



Now we have done the initial preparation. The forest and domain are ready to have the first Exchange 2010 server installed.
2. Install first Exchange 2010 server
We will do that on server "Bugis" which will have Client Access Role, Transport Role and Mailbox Role. But we will eventually remove the Mailbox role and deploy DAG on server "Outram", "Redhill" and "Dover". There is a reason behind why I choose to have 3 mailbox servers to form a DAG. That will be discussed in my future articles soon.
There are additional components needed before Exchange installation.,
As my first Exchange server is a combination all the 3 roles mentione above, I used the following command (refer the below screen capture)
ServerManagerCmd -i Web-Server Web-Metabase Web-Lgcy-Mgmt-Console Web-Basic-Auth Web-Windows-Auth Web-Net-Ext Web-Digest-Auth Web-Dyn-Compression NET-HTTP-Activation Web-ISAPI-Ext RPC-over-HTTP-proxy RSAT-ADDS






Here is the break down of what you will need to install in role level.
Client Access Role
ServerManagerCmd -i Web-Server Web-Metabase Web-Lgcy-Mgmt-Console Web-Basic-Auth Web-Windows-Auth Web-Net-Ext Web-Digest-Auth Web-Dyn-Compression NET-HTTP-Activation Web-ISAPI-Ext RPC-over-HTTP-proxy RSAT-ADDS
Transport Role
ServerManagerCmd -i Web-Server Web-Metabase Web-Lgcy-Mgmt-Console Web-Basic-Auth Web-Windows-Auth Web-Net-Ext RSAT-ADDS
Mailbox Role
ServerManagerCmd -i Web-Server Web-Metabase Web-Lgcy-Mgmt-Console Web-Basic-Auth Web-Windows-Auth Web-Net-Ext RSAT-ADDS
*For Mailbox Role, you have to install another component call "MSFilter Pack"
After the installation, you are required to perform restart server.




There are some updates & fixes need to be applied in specific.
Client Access Role
KB951725, KB950888, KB952664, KB953290
Transport Role
KB951725, KB950888, KB952664
Mailbox Role
KB951725, KB950888, KB952664
Now we are truly ready for the installation. I will not talk about installation using UI, because I prefer using command line.
Execute the command as shown in the screen capture below.


Here are the definitions of the parameters

/m = /mode
/r = /role, /roles
H = Transport or you can use HT
C = Client Access or you can use CA
M = Mailbox or you can use MB
Just hit "Enter" and sit back enjoy your coffee or newspaper. :-)





Thursday, February 17, 2011

SQL Server 2008 Installation process


A Step by Step guide to installing SQL Server 2008 simply and successfully with no prior knowledge
Developers and system administrators will find this installation guide useful, as will seasoned DBAs. It will teach you the basics required for a typical, problem-free installation of SQL Server 2008, allowing you to add other components later if you wish.
Remember to install the .Net Framework 3.5
Before you start the installation, you’ll need to install the .Net 3.5 Framework. This comes pre-installed on Windows 2008 Server, but for earlier versions of Windows, you’ll need to install it first. This is a straightforward pre-requisite and is usually included as part of the SQL Server 2008 installation. However, if you don’t know how to do this, or for some reason you need to download it, check out the guide Installing .Net Framework 3.5 for SQL Server 2008.
Once this Framework in installed you can commence the installation of SQL Server 2008.
STEP 1 : Copy the installation files
First off I’d recommend you copy the entire directory structure from the SQL Server 2008 installation disc to the C: drive of the machine you are going to install it on.
Although this means you need to grab a cup of coffee whilst it’s copying, this has three advantages:
  • It makes the installation process much faster than running it from CD/DVD once it gets started.
  • It allows you to easily add or remove components later, without having to hunt around for the CD/DVD.
  • If your media is damaged and a file won’t copy, you get to find out now, rather than halfway through the installation.
Here’s what my system looks like after the copy:

STEP 2 : Setup.exe
Double click on the setup.exe file.
After a few seconds a dialog box appears:

This will disappear from the screen and then the main installation page appears:

STEP 3 : SQL Server Installation Center
Click on the Installation hyperlink on the left hand side of the screen:

STEP 4 : SQL Server Installation Center
Click on the "New Server stand-alone installation" link on the right side of the screen:

The following dialog appears on the screen whilst the install program prepares for installation:

After a minute or so (the timing will vary according to your system), the following screen appears:

STEP 5 (optional) :
If any checks have failed, click on the Show details button or "View detailed report link" to find out the cause, correct it, then click on the Re-run button to perform the checks again.
STEP 6 : Product key
If all checks have passed, click on the OK button. After a few moments, the option to select the edition and to enter the license key (or “product key”) will appear. Note that the product key box may already be populated, depending on which edition you have. Don’t enter the product key we’ve shown here, it won’t work on your system!:

STEP 7 : License Terms
Enter the product key into the box, or choose the free edition if you're evaluating SQL Server 2008, and click on the Next button:
Click in the "I accept the license terms" check box, then click on the Next button again.
STEP 8 : Setup Support Files
The following screen appears; click on the Install button:

The following screen will appear whilst Windows Installer prepares itself for the installation. This will take a short while:

After 30 seconds or so the dialog appears again:

STEP 9 : Setup Support Rules
If all is well, the following screen appears:

Click on the Next button again.
STEP 10 : Feature Selection
Select the features you want to install.
At a minimum, the following are useful (I'd argue essential), but what you need will depend on your needs:

Click on the Next button.
STEP 11 : Instance Configuration
After a short while the following screen appears:

For most installations, keep the default settings.
Click on the Next button.
STEP 12 : Disk Space Requirements
This screen just tells you if you have sufficient disk space on the drive you’re installing to, and what’s going to be installed where.

Click on Next.

STEP 13 : Server Configuration
This step allows you to set up the service accounts that will be used to run SQL Server. If you have created Windows NT or Active Directory accounts for use with services, use these.
If not, then just to get the installation up and working, use the built-in Network Service account for all three services listed (this account does not require a password).
This allows SQL Server to start up after installation. However, it can be easily changed later to another account through the Services applet (Control Panel -> Administrator Tools -> Services):

In addition, remember to change the Startup Type to Automatic, for all three services. This automatically starts the SQL Server database engine, SQL Agent and SQL Browser services when the server is re-booted.
The first service runs the SQL Server database engines executable process. The other two services allow scheduled jobs to run after installation (and after a re-boot), and allow the SQL Server to be found by clients on the network.
Do not worry about changing the collation tab, unless there is a specific requirement for anything other than the default collation sequence. Finally, click on Next.
STEP 14 : Database Engine Configuration – Account Provision
This screen allows you to set up database engine security.



Change the Authentication Mode to Mixed Mode unless you are certain you only need Windows-only authentication.
  • Many third party applications rely on SQL Server logins to operate correctly, so if you are setting up a server for a third party application, rather than one developed in-house, enabling Mixed Mode authentication is a good idea.
If you pick Mixed Mode security, you must also enter a password for the sysadmin account (sa).
Enter and confirm a secure password for the sa account and keep it somewhere safe. Do not give it to any one you do not want to have access to the SQL Server.
Note that you MUST also provide a Windows NT account on the local machine as a SQL Server administrator. If you do not want Windows system administrators to be able walk up to the box and login to SQL Server, create a new, local, dummy Windows user and add this account instead. Otherwise, add in the local administrator account, or your own Windows account on the domain in which the SQL Server will reside.
STEP 15 : Database Engine Configuration – Data Directories
Click on the Data Directories tab.

Change the directories to specify which drives in your system will be used for the various types of database files.
Generally it’s advisable to put the User database directory and User log directory on separate physical drives for performance, but it will depend on how Windows has been configured and how many disk drives you have available.
If you are installing on a single drive laptop or desktop, then simply specify:
Data root directoryC:\Program Files\Microsoft SQL Server
User database directoryC:\Data
User log directoryC:\Logs
Temp DB directoryC:\TempDB
Temp Log directoryC:\TempDB
Backup directoryC:\Backups

Do not click on the FILESTREAM tab unless you know you need to change these options, as it is not generally required for most installations, but can easily be changed by using sp_configure 'filestream_access_level', ''after SQL Server has been installed. Click on Next.
STEP 16 : Error Usage Reporting
This screen simply asks if you want to send error information to Microsoft and can safely be skipped if you do not want to share any information.

Click boxes if you want to help Microsoft help you.
Click on Next again…
STEP 16 : Installation Rules
This screen simply checks if there are any processes or other installations running which will stop the installation of SQL Server 2008.

Click on Next again – you’re almost ready to install:
STEP 17 : Ready to Install
This screen summarises what you are about to install and gives you a last chance to cancel or change anything that’s wrongly configured:

Check that what’s being installed is what you want and then click on Install when you’re sure you want to start the installation process:
Installation Progress
SQL Server 2008 will now install. How long it takes depends on the speed of your machine, what load it’s under, the installation media (CD is slower) and what you’ve chosen to install.

More Installation Progress

... and Finally
Finally, the installation will complete:

...and the following dialog box will appear:

Click on OK, the machine will NOT reboot.
The following will appear:

…followed by:

Click on the Next button again...
STEP 18 : Installation Complete
The following screen appears:

It may be worth clicking on the installation log at the top of the screen to check everything’s gone as expected. Not that this is MUCH smaller than the usual SQL Server installation log files of old.
Finally, click on the Close button. The following dialog will appear:

Click on OK – your server will NOT re-boot at this point.
The dialog box will disappear and you will be returned to the Installation Center:

Click on the Close button (the “x”) in the top right of the screen.
Finally, manually reboot your machine to complete the SQL Server 2008 installation.
Top Tips :
How to check that SQL Server 2008 has installed correctly
Here are a short number of post-installation checks which are useful to perform after re-booting your new SQL Server. You don’t have to run these, and there are other ways to check, but they are very useful for non-DBAs to be sure that the installation is basically sound and a connection can be made to the new SQL Server before handing it over to someone else.
Check 1: Has the SQL Server Service Started?
Check SQL Server 2008 has started.

Check 2: Does Management Studio Work?
Check Management Studio works by firing it up.


Click on NO when you see this dialog box:




Check 3: Can you run a basic query against the new SQL Server?
Check SQL Server works by running a simple query from Management Studio:

Enter the query shown below and hit F5 to run it:

Check 4: Is SQL Server Agent Running?
Check SQL Server Agent is running for scheduled jobs. There should be a green arrow next to the SQL Server Agent database symbol (it’s small, you might have to look hard):

Check 5: Can SQL Server be seen from the Network?
Check that the new SQL Server can be seen from another SQL Server on the same domain by running isql –L (or osql –L):
If you can’t see the new SQL Server in this list, check that the SQL Server Browser service is started on the machine where you have just installed SQL Server.
Check 6: Has the TCP/IP network protocol library been enabled on the server?
If the browser service is started but you still cannot connect to the server, click on Start ->Programs -> SQL Server 2008 -> SQL Server Configuration Manager (on the server where SQL Server’s just been installed)

The SQL Server Configuration Manager window opens.
Click on the SQL Server Network Configuration node and expand it.
In the example below, we have MSSQLSERVER (a base instance of SQL Server), and SQLEXPRESS showing as installed.
If in doubt, click on Protocols for MSSQLSERVER.

In the above screenshot, the TCP/IP network protocol library is disabled. We need to enable it in order that remote servers can talk to the newly installed SQL Server.
  • A word of explanation : In most installations, Named Pipes can be ignored, unless there is a requirement for it. In virtually all environments, VIA can also be ignored as this protocol requires a special network card. Shared memory is the “local” protocol that SQL Server uses when talking to a client application on the same server as itself, for example when SQL Server Management Studio connects to it. It is usually best to leave this enabled.
You will need the TCP/IP protocol enabled if you need to connect to your new SQL Server from a remote client or another server via TCP/IP, which is what most networks use.
If it shows as DISABLED (above), double click on the TCP/IP protocol line, and the following window will appear:

Ensure that Enabled is set to Yes, and click on OK.
The following warning will appear:

Click on OK, and you will be returned to the Configuration Manager window, where TCP/IP will now be shown as enabled:

Go back to the Services applet, and re-start the MSSQLSERVER service so that the TCP/IP protocol can be used to connect to your new SQL Server.
Then try to connect to it again from a remote machine.

If you have experienced problems with the previous connectivity tests, you should now be able to repeat at least some of them successfully.