Search This Blog

Wednesday, October 12, 2011

Lync Server 2010 Deployment – Part 2

Lync Server 2010 Deployment – Part 2

 

Where Part 1 left off was just shy of deploying the Standard Edition server itself as most of the back-end configuration was completed.  A few additional steps will be left for later discussion (e.g. client Automatic Configuration DNS records) when those topics are addressed.  So for now left’s get the Lync Server deployed an functional.
Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.

Install Lync Server System

What these steps do is install a second SQL Express named instance (this one being named RTCLOCAL) on the local server which will contain a replica of the existing RTC named instance.  Although it may initially seem inefficient to have two SQL instances with duplicate data on the same server the separation of the Central Management Store and a CMS replica is key to how multiple server’s function in a single organization.
Only the first Standard Edition server in the organization would contain this authoritative RTC instance, while all other Lync Front End Servers (and even Edge Servers) would contain their own RTCLOCAL instance to replicate the Central Management Store data.  This approach also allows for the  new redundancy and availability features which were lacking in previous versions of OCS.  This RTCLOCAL instance can only ever be stored in an automatically installed SQL Express instance, it is not supported to locate this data in a full SQL Server instance.
  • Back at the Deployment Wizard main menu select Install or Update Lync Server System. Run Step 1: Install Local Configuration Store and leave the default setting to Retrieve the configuration data directly from the Central Management Store.  By reviewing the results in the execution window we can confirm a number of actions, most importantly that the second SQL Express instance of RTCLOCAL was installed.
<snipped>
Checking prerequisite PowerShell2…prerequisite satisfied.
Checking prerequisite SqlExpressRtcLocal…installing…success
Checking prerequisite VCredist…prerequisite satisfied.
Checking prerequisite SqlNativeClient…prerequisite satisfied.
Checking prerequisite SqlBackcompat…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied.
Installing OcsCore.msi(Feature_LocalMgmtStore)…success

  • Secondly the Local Configuration Store was installed and enabled using the Import-CsConfiguration and Enable-CSReplica cmdlets.
> Install Local Configuration Store Import-CSConfiguration -FileName "C:\Users\ADMINI~1.CSM\AppData\Local\Temp2\CSConfigData-2010_09_15-12_19_04.zip" -Verbose -LocalStore
> Enable local replica service Enable-CSReplica -Verbose -Confirm:$false -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Enable-CSReplica-[2010_09_15][12_10_23].html"
  • To confirm the location of the RTCLOCAL database files on the server check the default SQL Server installation directory for the existence of the xds files.
image
  • Run Step 2: Setup or Remove Lync Server Components and if the process halts with an error requesting a reboot as shown below then restart the server and run this step again.  This can occur because the Windows Media Format Runtime package requires a server restart after installation.
Checking prerequisite Wmf2008R2…installing…failure code 3010
The server must be restarted before installation can continue. To continue the installation after the server has restarted, start the Deployment Wizard and complete this step again.
image
  • At the completion of this step all of the Lync Server services and components have been installed locally.  A look at the Services applet will show a large list of installed services which are not yet running as a certificate still needs to be configured and assigned to them.
image
  • Some of the newly added database files for the pool can be seen in the default SQL Server DATA directory as well.
image

So about now would be a good time to briefly sidebar and try to understand what is going on with all these different SQL instances and databases with similar names. I was scratching my head as well the first time I installed all this in an early beta release.  So basically here is a brief rundown of
  • Using SSMS there are two instances (both SQL Express) on the Lync Server, RTC and RTCLOCAL on the server to connect to, each with a different set of databases.
image
Instance Database Description
RTC lis Location Information Services data
RTC xds Central Management Store data
RTCLOCAL rtc Standard Edition Pool data
RTCLOCAL rtcdyn Standard Edition transient user data
RTCLOCAL xds Local replica of Central Management Store data
 
And now moving back into the server deployment the next pending step is to request and assign a certificate so that the services can be started.
  • Run Step 3: Request, Install or Assign Certificates and then expand the Default Certificate entry to verify that all roles are checked.  Click Request and enter the information listed in the following tables.
Delayed or Immediate Requests
Send the request immediately to an online certificate authority

Choose a certificate Authority
Select from a list detected in your environment
(LAB1DC.csmvp.net\CSMVP-RootCA)

Certificate Authority Account
(skipped)

Specify Alternate Certificate Template
(skipped)

Name and Security Settings
Friendly Name Lync SE Certificate
Bit Length 2048

Organization Information
Organization <Company Name>
Organizational Unit <Department Name>

Geographical Information
Country/Region United States
State/Province IL
City/Locality Chicago

Subject Name / Subject Alternate Names
Subject Name lab1ls.csmvp.net
Subject Alternate Name lab1ls.csmvp.net
dial.csmvp.net
meet.csmvp.net
admin.csmvp.net
external.csmvp.net

SIP Domain setting on Subject Alternate Names (SANs)
Configured SIP Domains csmvp.net

Configure Additional Subject Alternate Names
(skipped)

  • This process will execute the Request-CsCertificate cmdlet with the provided configuration information, performing and online request against the CA and then automatically importing the return certificate into the Local Computer store.
> Request Certificate
Request-CSCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -CA "LAB1DC.csmvp.net\CSMVP-RootCA" -Country US -State "IL" -City "Chicago" -FriendlyName "Lync SE Certificate" -KeySize 2048 -PrivateKeyExportable $False -Organization "Schertz Lab" -DomainName "sip.csmvp.net" -Verbose -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Request-CSCertificate-[2010_09_15][14_55_56].html"
  • Click Assign and select the new certificate from the local store.  The following Set-CsCertificate cmdlet is automatically run by the wizard to assign the desired certificate to the three server roles.
> Assign Certificate
Set-CSCertificate -Type Default,WebServicesInternal,WebServicesExternal -Thumbprint 7B8E17E800F4702EC14228C4A6E84C019F9F6AB6 -Verbose -Confirm:$false -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Set-CSCertificate-[2010_09_15][15_03_04].html"
  • Once the certificate is assigned to all roles the wizard should reflect that, although a Refresh may need to be required to see the changes.
image
  • Run Step 4: Start Services to see the fruits of your labor converted into a bunch of happily-running services.  The Start-CsWindowsService cmdlet is executed with no parameters which by default will attempt to start all Lync services.
> Start Services
Start-CSWindowsService -NoWait -Verbose -Report "C:\Users\administrator.CSMVP\AppData\Local\Temp2\Start-CSWindowsService-[2010_09_15][15_40_36].html"
Let us briefly take a look at another major difference between OCS and Lync which is how IIS is configured by the installation process.
  • For one, certificates previously had to be manually defined and SSL enabled in IIS, but in Lync Server the setup wizard now does this automatically.
image
  • The other noticeable difference is the amount of new Application Pool defined, as well as the separate internal and external web sites.
 image
Because there was no step in the deployment asking for additional IP addresses and it is still a best practice to use a single IP address on the Standard Edition server the External and Internal web sites in IIS are clearly not configured on the same listening ports.
  • The Lync Server Internal Web Site shows the default TCP80 and TCP443 ports assigned to it.
image
  • Yet the Lync Server External Web Site indicates different listening ports of TCP8080 and TCP4443 ports.  This configuration indicates that an external publishing server (e.g. ISA Server) must be configured to listen for client connections on the standard 80 and 443 ports yet it will forward traffic to the internal Front End server over ports 8080 and 4443 so that external client connections are directed to the External Web Site.
 image
Before enabling user accounts now would be a good time to add the required internal DNS records to support Automatic Configuration. This is allow for any AD Integrated replication to fully propagate the new DNS records before attempting to sign-in with the Lync client.
  • Create a DNS Service Locator (SRV) and Host (A) records on the internal DNS server’s forward lookup zone.
image
As a general best practice I always prefer to add a second DNS record which the client will use as a fallback during Automatic Configuration in the case that the SRV record is not available or unsupported.  The Communicator and Lync clients will automatically lookup sipinternal, sip, and sipexternal host records in the SIP domain if the SRV lookup first fails.
  • A quick look at the details of the requested certificate shows an additional entry for sip.csmvp.net in the Subject Alternate Name field even though it was now specifically entered in the certificate wizard.  The ‘Configured SIP Domain’ which was identified as csmvp.net during the setup automatically added a “sip.” record for that domain, so that record will suit our purposes.
 image
  • Create a new DNS Host (A) record on the internal DNS server’s forward lookup zone for the desired SIP domain (e.g. sip.csmvp.net) and provide the same IP address which is statically assigned to the Lync Front End server.
image
  • Verify the new records using the following nslookup commands from the standard Windows Command Prompt.
    C:>nslookup -q=srv _sipinternaltls._tcp.csmvp.net
  _sipinternaltls._tcp.csmvp.net  SRV service location:
              priority       = 0
              weight         = 0
              port           = 5061
              svr hostname   = lab1ls.csmvp.net 
  lab1ls.csmvp.net        internet address = 192.168.207.11

  C:>nslookup sip.csmvp.net
  Name:    sip.csmvp.net 
  Address:  192.168.207.11

Lync Control Panel

In a major shift away from MMC-based management consoles Lync Server can only be managed by either the Silverlight-based Lync Server Control Panel or the PowerShell-based Lync Server Management Shell.
  • Launch the Lync Server Control Panel from the Microsoft Lync Server 2010 (RC) program group and re-enter the current account’s credentials. (Make sure this account has been added to the CsAdministrator domain group as covered in the Part 1 article.)
image
  • (Optional Step) In order to suppress the additional authentication prompt when opening the control panel then on local server go to Internet Options > Security > Local Intranet > Sites > Advanced and add the FQDN of the Lync Server to the zone (e.g. https://lab1ls.csmvp.net).
image
At this point we should have a fully functional Lync Server and are ready to start configuring accounts, policies, and additional services.  Part 3 in this series moves on to enable a few user accounts for Lync Server to test client connections to the Front End server.

Lync Server 2010 Deployment

Lync Server 2010 Deployment – Part 1

Now that the general public has access to the Release Candidate software for Lync Server 2010 it is now appropriate to cover the deployment process in depth. The purpose of this article is to take a look at what the installation process actually does in order to generate a deeper understanding of the product. Not just simply follow a bunch of screenshots of the deployment wizard.

I’m starting with the Standard Edition as this is both the simpler approach and the more common deployment for testing purposes.  A host of new features and concepts have been introduced which are all available in single-server Standard Edition pool, not to mention that the required amount of individual physical hosts have been reduced thanks to improved collocation support.  So a single Windows Server can now fill the role of both a consolidated Standard Edition server and a Mediation server.  Additional roles like the Monitoring Server can also be collocated with the Standard Edition server, but a full SQL Server installation must be performed on the server prior to deploying Lync Server on it.  Previous versions of OCS Standard Edition did not support this level of co-mingling, or support anything but the default SQL Express instance.
For the purposes of this walkthrough I will start to introduce a number of PowerShell cmdlets in some of the processes, but understanding that PowerShell may still be new to many people I will utilize the deployment wizard throughout the majority of the steps.  Later on I plan to document a complete Lync Server deployment using PowerShell cmdlets at every possible step.
Much of this process is already detailed in Microsoft’s official Lync Server 2010 (RC) Lab Deployment Guide but I’ve gone into further details on many of the steps, as well as mixed up some of the order as a few of the prerequisite steps are redundant.  That document also includes configuration and deployment steps for a Director and Edge Server which I will not cover now, but will address in later articles.
Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.

Environment

  • Physical Host: Windows Server 2008 R2 Hyper-V running on a Core2 Duo desktop-class system with 8GB RAM.
  • Domain Controller: A single Windows Server 2003 guest promoted to a domain controller for the new Active Directory forest root domain of csmvp.net.  (Newer versions of Windows Server 2008 can be used but for the sake of saving precious RAM resources on my lab server I opted for Server 2003.)
  • Lync Server: A second virtual guest running Windows Server 2008 R2 x64 Enterprise and joined to the csmvp.net domain.
  • The domain account used to perform all steps is a member of the Domain Admins, Enterprise Admins, and Schema Admins domain security groups.
  • The Forest and Domain functional levels were elevated to Windows Server 2003.
  • A Windows Enterprise Certificate Authority was deployed on the DC.

Active Directory Preparation

Before we can run any of the AD preparation steps included in the deployment wizard a few server prerequisites must first be installed.  The various IIS features are not required until just prior to deploying the Lync Server components but for simplicities sake installing all features in one step is best.
  • Launch Windows PowerShell buy selecting ‘Run As Administrator’ and enter the following cmdlets to quickly install the .NET Framework 3.5.1 package, the Remote Server Administrative Tools, and all IIS7 features then perform the required server reboot. (The Telnet Client is not a requirement but I always install the feature as it is a handy troubleshooting tool. If Windows Server 2008 SP2 is used then PowerShell 2.0 will also need to be installed).
PS C:> Import-Module ServerManager
PS C:> Add-WindowsFeature NET-Framework,RSAT-ADDS,Telnet-Client,Web-Server,Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Http-Redirect,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Logging,Web-Log-Libraries,Web-Http-Tracing,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Scripting-Tools -Restart
  • From the installation media launch the setup wizard found at the following location:
\Setup\amd64\setup.exe
  • At this point the setup will automatically ask to install the Microsoft Visual C++ 2008 Redistributable x64 package.  Confirm and wait for the next setup window to appear. (It may take a minute as the installation runs in silent mode, but also keep an eye on the taskbar as the installation window likes to pop-up behind other windows.  Also note that this process no longer leaves a bunch of files on the root of the drive where it is installed as the previous OCS installation used to.)
image
  • Accept the default Installation Location, or enter a different path, and select Install. Then accept the End User License Agreement.
C:\Program Files\Microsoft Lync Server 2010
  • From the main menu select Install Topology Builder to install the Administrator Tools on the local server.  This will install the Lync Server Management Shell which will be used to execute a few cmdlets to verify various AD preparation steps.
image 
  • From the Deployment Wizard select Prepare Active Directory. Run Step 1: Prepare Schema and review the log to verify no errors were reported.  Verify the process using has completed successfully by checking the rangeUpper (1100) and rangeLower (14) values of the ms-RTC-SIP-SchemaVersion Schema object with adsiedit.msc.
image
  • Run Step 2: Prepare Forest and use the settings in the table below.  Review the results log to verify no errors were reported.
Universal Group Location Local Domain
  • Verify that the forest preparation was successful by executing the following cmdlet from the Lync Server Management Shell and looking for a response of LC_FORESTSETTINGS_STATE_READY.
PS C:> Get-CsAdForest
LC_FORESTSETTINGS_STATE_READY
  • Run Step 3: Prepare Domain and review the log to verify no errors were reported.  Verify that the process was successful by executing the following cmdlet from the Lync Server Management Shell and looking for a response of LC_DOMAINSETTINGS_STATE_READY.
PS C:> Get-CsAdDomain
LC_DOMAINSETTINGS_STATE_READY

Server Preparation

In previous beta builds a number of prerequisite supporting installations had to be manually deployed, but in the Release Candidate we see our first glimpse of how the upcoming RTM product will smoothly handle all of these for us.
This process will install the SQL 2008 Native Client and SQL Server 2008 Express, as well as configure firewall exceptions for SQL. Mostly importantly it also deploys the first SQL Express named instance, simply called RTC.  This instance will be the default location for the Central Management Store which is where Lync will store the majority of the global (forest-wide) configuration data.  The RTC Service container in the AD Configuration partition is still used to store some data, but mainly for coexistence with previous versions of OCS.
  • From the main Deployment Wizard menu select Prepare first Standard Edition server.
<snipped>
Checking prerequisite WMIEnabled…prerequisite satisfied.
Checking prerequisite NoOtherVersionInstalled…prerequisite satisfied.
Checking prerequisite SupportedOS…prerequisite satisfied.
Checking prerequisite PowerShell2…prerequisite satisfied.
Checking prerequisite VCredist…prerequisite satisfied.
Checking prerequisite SqlNativeClient…installing…success
Checking prerequisite SqlBackcompat…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied.
Checking prerequisite SqlExpressRtc…installing…success

> Creating firewall exception for SQL instance
netsh advfirewall firewall add rule name="OCS SQL RTC Access" dir=in action=allow program="c:Program Files\Microsoft SQL Server\MSSQL10.RTC\MSSQL\Binn\sqlservr.exe" enable=yes profile=any
Ok.
> Creating firewall exception for SQL Browser
netsh advfirewall firewall add rule name="SQL Browser" dir=in action=allow protocol=UDP localport=1434
Ok.
  • A quick glance at the Programs and Features control panel shows all of the components which were just installed.
image
  • Also locate and launch the SQL Server Configuration Manager to verify the local SQL services are properly installed and running.
image
  • The newly installed SQL Server Express instance default database files can be found in the following default location:
image
  • In a slight change from previous versions of Communications Server it’s not enough to simply be logged in as a Domain Admin to fully administer the Lync Server environment.  Before moving further the domain Administrator account used throughout this process should be added as a member to the domain security groups CsAdministrator and RTCUniversalServerAdmins.
image
  • This user account should then logoff and back on to the Windows Server where Lync is being installed to update the associated security token.  Once logged back on use the following commands in the Windows Command Prompt to verify the new group membership:
C:> whoami /groups /fo list | findstr /i CsAdmin
Group Name: CSMVP\CSAdministrator

C:>whoami /groups /fo list | findstr /i RTCUniv
Group Name: CSMVP\RTCUniversalGlobalReadOnlyGroup
Group Name: CSMVP\RTCUniversalUserReadOnlyGroup
Group Name: CSMVP\RTCUniversalServerAdmins
Group Name: CSMVP\RTCUniversalServerReadOnlyGroup
Group Name: CSMVP\RTCUniversalGlobalWriteGroup
The final preparation step is to manually create a file share on the server which will later be referenced during the Lync Server topology configuration.
  • Create a new folder on the server named lyncshare anywhere on the server.  The following path was used in this lab deployment:
C:\Program Files\Microsoft Lync Server 2010\LyncShare
  • Configure the NTFS file security on the new  folder to grant Read & Execute permissions to Everyone.
  • Also verify that the Administrators group is already granted Full Control.
  • Then enable file sharing with the Share name of lyncshare and configure the share permissions so the administrator account used to perform the installation is granted Full Control.  A later server deployment process will customize the share and file permissions accordingly.
image     image

Topology Builder

Because the Lab Deployment Guide uses the Planning Tool and this is not required I will instead walkthrough the basic Topology Builder process.
  • Launch the Lync Server Topology Builder application found in the Microsoft Lync Server 2010 (RC) program group.
  • Select New Topology from initial prompt and save the .tbxml file with any desired name (e.g. chicago.tbxml).
  • For the Primary SIP domain enter the desired domain namespace (e.g. csmvp.net). This does not have to be the same namespace utilized by Active Directory.  If an Exchange Server or other messaging platform exists in this forest then whatever the current primary SMTP namespace is should typically be selected as the SIP domain as well.
  • Do not add an additional supported domains at this point unless desired.  A single SIP domain is sufficient to test all of the features of Lync Server in a lab environment.
  • Define the Name (e.g. Chicago) and Description (e.g. Main Site) of the first site.  This is also a new component of Lync Server as previous versions did not include and type of site definition.  The site information will be used by many of the new resiliency features in Lync Server.
  • Provide City, State/Province, and Country/Region Code information specific to your first site.
  • Complete the topology definition and open the New Front End Wizard.
image
  • In the Define New Front End Pool wizard select the following options and enter the desired information specific to your own lab.  The pool FQDN should be the FQDN of the server where you will be installing the Lync Server Standard Edition server components.
Define the Front End Pool FQDN
FQDN lab1ls.csmvp.net
Type Standard Edition Server

Select Features
  • Conferencing, which includes audio, video, and application sharing
  • Dial-In Conferencing
  • Enterprise Voice
  • Call Admission Control
Select Collocated Server Roles
  • Collocate A/V Conferencing Server
  • Collocate Mediation Server
Associate Server Roles with this Front End Pool
  • (Leave all options unchecked )
Define the SQL Store
  • Because this is a standard Edition installation and SQL Express has already been deployed all options are disabled.  The default RTC instance on the local server will be used.
Define the File Share
File Server FQDN lab1ls.csmvp.net
File Share lyncshare

Specify the Web Services URL
Internal Base URL lab1ls.csmvp.net
External Base URL external.csmvp.net

Specify PSTN Gateways
  • Leave these options blank for now as Enterprise Voice will be enabled in a later article.
  • Back at the main Topology Builder window select Edit Properties on the Lync Server 2010 (RC) root-level object.  Highlight the Simple URLs section and enter the desired Administrative Access URL. (Note the additional for Phone Access URLs and Meeting URLs are already configured.)
https://admin.csmvp.net
  • Also highlight the Central Management Server section and select the new Front-End server from the drop-down menu if it is not already selected.
image
At this point it is now time to publish the topology which will populate the RTC instance with new databases, create the folder structure in the shared directory, and publish configuration settings into the CMS and Active Directory.
  • From the Action menu select Publish Topology.  Select the local server FQDN for the Central Management Store location which should be the only option in the drop-down menu.  If all previous configuration steps were completed correctly then the wizard should complete successfully.
image
As indicated by the To-Do List shown under Next Steps a couple of DNS records will need to be manually created to match the FQDN set in the Lync Server topology.
  • Create new DNS Host (A) records on the internal DNS server’s forward lookup zone which matches the SIP domain used.  Each record should point to the static IP address used by the server where the Standard Edition roles will be deployed.
image 
To validate and understand the changes the Topology Builder has applied to Active Directory there are a number of places to look throughout the various results logs, within Active Directory, and the SQL databases themselves.
  • Highlight Setting Central Management Store location… on the Publishing wizard complete window and select View Logs.  This log shows that the Set-CsConfigurationStoreLocation cmdlet was used to define the location of the CMS for all future Lync Servers to know how to locate the forest’s configuration data.
image 
  • Use adsiedit.msc to view the Configuration context and browse to the path shown below.  View the properties on the only object in the Global Settings container to see that the supplied configuration data among the attribute values.  Also note that the whenCreated attribute should coincide with the time the topology was just published.
CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=csmvp,DC=net
image
  • From another computer on the network with SQL Server 2008 Management Studio Express installed the SQL Server Management Studio can be used to connect to the RTC instance on the Lync Server to view the databases.  Here we see the XDS and LIS databases created by the CMS setup.
image
  • The raw database files can be found on the Lync Server in the default installation directory shown below.
image
  • Additionally the manually defined file share is now populated with new folder structure.
image

Summary

At this point all organization preparation steps have been completed and the next step is to actually install the Standard Edition server components
.
The next article in this series jumps right into that process with Part 2.

 http://blog.schertz.name

Wednesday, October 5, 2011

Mọi việc trên đời Đừng làm đại khái

Mọi việc trên đời
Đừng làm đại khái
Khi bạn đi đái
Tụt hẳn quần ra
Nếu không sợ ma
Tắt đèn khi ngủ
Mụn đang mưng mủ
Chớ có nặn liều
Cô bạn mới yêu
Đừng đòi … ấy vội
Gặp thằng sởi lởi
Cẩn thận bị lừa
Gặp con đong đưa
… Cài quần cho chặt
Có em thắc mắc
Mười bảy tuổi rồi
Mà sao núi đồi
Vẫn chưa thấy nhú
Có cậu lại cú
Người thì lớn lên
Mà nhìn thằng em
Vẫn như cát-tút
Gặp nhau là gut!
Cát tút sẽ dài
Núi đồi sẽ mọc
Hãy đừng hấp tấp
Mọi việc trên đời

Tuesday, September 6, 2011

Tuyển môi xinh 1


Tổng quan về Lotus Domino

Lotus Notes/Domino là gì?
Hệ thống Lotus Notes/ Domino là một hệ thống tích hợp thư tín điện tử và các ứng dụng Web, cho các công ty, tổ chức có thể cải thiện khả năng đáp ứng yêu cầu khách hàng và tiến trình thương mại của họ.
Domino là một giải pháp mở, có kiến trúc thống nhất, đã được các công ty lớn trên thế giới tin tưởng để xây dựng các hệ thống thông tin bảo mật, các ứng dụng mang tính chất cộng tác và thương mại. Các máy chủ Domino đã cài đặt một hệ thống tiêu chuẩn với Internet, đơn giản trong quản trị hệ thống và tích hợp với các hệ thống nền. Với quá trình phát triển lâu dài, Lotus Notes/ Domino đã vượt qua các rào cản về sử dụng chung tài nguyên, quản lý hệ thống, phân phối thông tin, trợ giúp người sử dụng với các tiến trình đồng bộ và tự động, đã giúp cho khách hàng cải tiến các hoạt động trong công ty mình.
Lotus Notes/ Domino làm cho các tiến trình thông tin, cộng tác và phối hợp giữa các nhân viên trong công ty được đồng bộ và dễ dàng. Nó là sự kết hợp của các cơ sở dữ liệu hướng văn bản, một cơ sở hạ tầng về thư tín điện tử mởi rộng và sự phát triển ứng dụng có thể chạy trên nhiều hệ điều hành.
Lotus Notes/ Domino đang dẫn đầu trong thị trường phần mềm mô hình Client/Server cho hệ thống thông tin cộng tác và thương mại điện tử. Với sức mạnh của hệ thư tín điện tử và truyền dẫn dữ liệu, nó có thể mang đến cho bạn tất cả những thông tin mà bạn cần như:
  • Thư tín điện tử (Email)
  • Lịch làm việc
  • Các công việc cần làm ( To do list)
  • Sổ địa chỉ ( Address book)
  • Tìm kiếm địa chỉ trên Internet
  • Trình duyệt Web
  • Phần mềm thư tín theo chuẩn Internet
  • Bảo mật thông qua chứng thực điện tử
 Các phần mềm trong hệ thống Lotus

1. Phần mềm phía máy chủ
  • Domino Application Server
 Domino Application Server là sự kết hợp giữa hệ thống thư tín điện tử và các máy chủ ứng dụng. Hệ thống này làm cho người sử dụng đơn giản trong việc tích hợp các hệ thống nền với các tiến trình thương mại. Các ứng dụng được phát triển nền các máy chủ này được sử dụng tính năng thư điện tử tạo ra các ứng dụng mang tính cộng tác và đồng bộ.
  • Domino Messaging Server
Domino Messaging Server được sử dụng cho hệ thống thư điện tử, lịch và thời khóa biểu. Nó đã được xây dựng sẵn bên trong một hệ thống e-mail và ứng dụng cộng tác bao gồm cả diễn đàn thảo luận. Domino Messaging Server kết hợp sự hỗ trợ các công nghệ mới nhất của Internet với các đặc điểm tiên tiến của hệ thống thư điện tử, khả năng tin cậy và tốc độ cao.
  • Domino Enterprise Server
Domino Enterprise Server hỗ trợ giống như Domino Application Server, nhưng cộng thêm vào đó khả năng hỗ trợ về cluster và khả năng sẵn sàng đáp ứng cao.

2. Phần mềm phía máy trạm - Lotus Notes
  • Domino Designer: dùng cho các máy trạm phát triển ứng dụng ( giống như với Visual Studio)
  • Domino Administrator: dùng cho máy trạm quản trị hệ thống
  • Mobile Client
  • iNote Web Access
  • iNote for Microsoft Outlook

Wednesday, August 10, 2011

Chính sách bảo mật cho Web Server

Bài viết này là một phần của bài "Securing Your Web Server", chương 16. Mục đích của bài viết này để định hướng và thực hiện chính sách bảo mật cho Web Server của bạn



Về Patches và Updates:



Các Tool cho IIS
  • IISLockdown phải được setup và chạy trên server
  • URLScan phải được setup, tinh chỉnh và chạy trên server


Về các ứng dụng
  • Phải disable các ứng dụng không cần thiết
  • Các ứng dụng phải được chạy với account có quyền tối thiểu
  • Các ứng dụng như FTP, SMTP, và NNTP phải disable nếu không sử dụng
  • Phải tắt Telnet
  • ASP .NET Service State phải được disable và không dùng bởi bất kì ứng dụng khác. Vào Start > Run > gõ services.msc, tìm service ASP .NET Service State để kiểm tra chắc chắn service này được disable.


Về Protocols
  • WebDAV phải được tắt nếu không sử dụng hoặc phải được sucure nếu cần. Thông tin về WebDAV, các bạn có thể xem thêm tại Microsoft Knowledge Base article 323470, "How To: Create a Secure WebDAV Publishing Directory"
  • TCP/IP phải được config kỹ.
  • NetBIOS and SMB phải được disabled (đóng các ports 137, 138, 139, và 445).


Về Accounts
  • Những account không sử dụng đến phải được xóa bỏ
  • Phải tắt (disable) account Guest.
  • Account Administrator phải được đổi sang tên khác, và phải đặt password phức tạp
  • Account IUSR_MACHINE phải được tắt nếu không dùng đến
  • Nếu các ứng dụng cần quyền anonymous access, các bạn phải create account anonymous này với quyền thấp nhất có thể
  • Những account anonymous không được phép có quyền write vào thư mục web và không được truy cập vào những ứng dụng bằng command line
  • Các account chạy ứng dụng ASP.NET phải được thiết lập với quyền thấp nhất. (Chỉ áp dụng khi bạn không dùng account ASPNET - account mặc định chạy ứng dụng ASP.NET với quyền mặc định thấp nhất)
  • Phải có chính sách về account và password phức tạp thiết lập trên sever.
  • Phải remove group Everyone trên policy "Access this computer from the network"
  • Các account quản trị phải được đảm bảo tính bảo mật, không chia sẽ thông tin các account này.
  • Null sessions (anonymous logons) phải được tắt
  • Group Administrator không tồn tại quá 2 accounts.
  • Remote logon phải được đảm bảo secure cho account Administrators.
Về Files và cấu trúc thư mục
  • Tất cả các partition phải được setup NTFS
  • Thư mục Web phải được đặt ở partition khác với partition chứa files hệ thống
  • Log files phải được đặt ở thư mục hoặc partition khác với 2 partition chứa Web và Files hệ thống
  • Group Everyone phải được thiết lập để không có quyền truy cập vào thư mục chứa files hệ thống như \Windows hay \Windows\System32 ... đồng thời cũng không có quyền truy cập vào Thư mục hay partition chứa Web
  • Account Tnternet Guest phải được thiết lập tuyệt đối không có quyền write vào thư mục chứa Web
  • Remote IIS Administration phải được xóa hay disable (\Windows\System32\Inetsrv\IISAdmin).
  • Resource Kit Tools, Utilities, và các SDKs phải được xóa bỏ hay disable
  • Các Sample của IIS phải được xóa (\Windows\Help\IISHelp, \Inetpub\IISSamples).

Shares
  • Những shares không cần thiết phải được removeAll unnecessary shares are removed (including default administration shares).
  • Group Everyone không được thiết lập để có thể truy cập vào các shares
  • Các Administrative shares (như C$ D$ E$ ... và Admin$) phải được xóa nếu không cần thiết (Chỉ có Microsoft Management Server (SMS) và Microsoft Operations Manager (MOM) sử dụng các Shares trên).

Ports
  • Cấm truy xuất internet cho Web Server (đóng các outbound port 80, 8080 ... hoặc có thể remove Internet Explorer)
  • Intranet traffic phải được mã hóa (ví dụ mã hóa với SSL)

Registry
  • Remote registry phải tắt.
  • SAM phải được bảo vệ (HKLM\System\CurrentControlSet\Control\LSA\NoLMHash).
Các chính sách sau chỉ áp dụng cho StandAlone Server

Logging
  • Login failed phải được server ghi nhận.
  • IIS log files phải được thay đổi đường dẫn và phải được bảo vệ.
  • Dung lượng log files phải được thiết lập thích hợp.
  • Log files phải được kiểm tra thường xuyên.
  • Các truy cập vào Metabase.bin phải được ghi nhận.
  • IIS log phải được configured dạng W3C.

Sites and Virtual Directories
  • Web sites phải được đặt ở partition khác với partition chứa system (non-system partition.)
  • "Parent paths" phải được disable.
  • Các virtual directories nguy hiểm như IISSamples, IISAdmin, IISHelp, và các Scripts virtual directories phải được remove
  • MSADC virtual directory (RDS) phải được remove hoặc được bảo vệ
  • Các Virtual directories cho phép truy cập anonymous access phải disable quyền Write và Excute
  • Chỉ set quyền write cho những folders yêu cầu có authentication (dùng SSL nếu cần thiết)
  • FrontPage Server Extensions (FPSE) phải được remove nếu không dùng đến.

Script Mappings
  • Nên chuyển (mapping) các Extensions không dùng đến sang 404.dll (ví dụ như .idq, .htw, .ida, .shtml, .shtm, .stm, idc, .htr, .printer).
  • Những extension không cần thiết của ASP.NET nên mapped đến "HttpForbiddenHandler" ở Machine.config.

ISAPI Filters
  • Những ISAPI filters không cần thiết hay không dùng đến phải được removed

IIS Metabase
  • Truy cập vào Metabase phải được ghi nhận và phải được giới hạn bằng cách dùng NTFS permissions (%systemroot%\system32\inetsrv\metabase.bin).
  • IIS banner information phải được giới hạn sử dụng


Other Check Points
  • IISLockdown và URLScan tool phải được setup và chạy trên server
  • Remote administration phải được bảo vệ và mã hóa (SSL). Nên thiết lập low session time-outs và account lockouts.

Hạn chế DOS và Những điều không nên thực hiện ở Web Server
* Phải setup Web Server như một server riêng biệt
* Nơi đặt server phải được bảo vệ nghiêm ngặt (physically protect)
* Thiết lập các anonymous accounts khác nhau cho từng application khác nhau
* Không nên install IIS server trên một domain controller
* Không nên kết nối internet cho IIS server khi chưa thiết lập kỹ các chính sách security
* Không cho phép Group Anyone truy cập Locally. Logon Locally chỉ nên có 1 group duy nhất là Administrators

LDP - Nhất Nghệ

Thursday, July 21, 2011

Configuring Single-Sign On for SharePoint

As you learned in a previous blog, Single Sign-On (SSO) enables SharePoint users to authenticate only once when they access applications through SharePoint sites. In this blog I will review the steps necessary to configure SSO in your SharePoint farm. Before we proceed with the configuration the following conditions must be met:
  • Your server must belong to an Active Directory domain.
  • Your server must be connected to a domain controller.
  • You must use a domain user account (not a group account).
  • You must use a SharePoint server farm account.
  • You must be a member of the local Administrators group on the encryption-key server (which is the first server where we will start SSOSrv).
  • You must be a member of the Security Administrators role and db_creator role on the computer running SQL Server.
  • You must belong to the single sign-on administrators group.
Setting Up and Starting the Single Sign-On Service
  1. Go to the Start menu and select All Programs –> Administrative Tools –> Computer Management.
  2. Expand Services and Applications.
  3. Click Services.
  4. Locate Microsoft Single Sign-On Service and rt-click.
  5. Select Properties.
  6. On the General tab of the properties window, click the Startup Type drop down menu and select Automatic.
  7. On the same tab, under Service status, click the Start button.
    SSO Properties
  8. Click Ok to close the properties window.
Configuring the Single Sign-On ServiceÂ
You will need to perform these steps on each server in your server farm. Once the service is started we can now go configure SSO settings in Central Administration.
  1. Open the Central Administration web application.
  2. Navigate to the Operations page.
  3. In the Security Configuration section, click Manage Settings for Single Sign-On.
    Manage Settings for Single Sign-On
  4. On the Manage Server Settings page, click the Manage Server Settings link.
    Manage Settings for Single Sign-On
  5. Enter the Single Sign-On administrator account name using the domain\username format. Note: The group or user specified here must meet all of the following criteria:
    • A Windows global group or individual user account – cannot be a domain local group account or a distribution list.
    • If a user is specified, the user must belong to the same account as the SSO service account and the configuration account for SSO.
    • If a group is specified, the SSO service account must be a member of that group and the configuration account for SSO must be a member of that group.
    • They must be a member of the Farm Administrators group on Central Administration.
  6. Enter the Enterprise Application Definition Administrator Account. (This user or group must be member of the SharePoint Readers group on Central Administration).
  7. In the Database Settings Section, enter the NetBIOS name of the single sign-on database server.
  8. Enter the Database Name.
  9. Enter the Time Out settings. The default value is 2 minutes.
  10. Enter the Delete Audit Log Records Older than value. The default value is 10.
    Manage Settings for Single Sign-On
  11. Click OK.
Creating an Encryption Key
  1. Navigate to the Manage Settings for Single Sign-On page.
  2. In the Server Settings section, click the Manage Encryption Key link.
    Manage Settings for Single Sign-On Encryption Key
  3. Click Create Encryption Key.
  4. Check the New Encryption Key checkbox.
  5. Click OK.
Backing Up the Encryption Key
  1. Navigate to the Manage Settings for Single Sign-On page.
  2. In the Server Settings section, click the Manage Encryption Key link.
  3. Navigate to the location where you want to backup the encryption key. This must be a removable storage device.
  4. Click Back Up.
Restoring the Encryption Key
  1. Navigate to the Manage Settings for Single Sign-On page.
  2. In the Server Settings section, click the Manage Encryption Key link.
  3. Navigate to the location where you placed the backup encryption key. This must be a removable storage device.
  4. Click Restore. 
Note: You should always backup the encryption key when you backup the database. In Part 2 I will explain how to configure account information for an Enterprise Application Definition.

In the previous blog you learned how to setup and configure Single Sign-On (SSO) for SharePoint. In the SSO environment, the back-end or external data sources are referred to as “enterprise applications”. An enterprise application definition needs to be configured for each external data source that SharePoint will connect to. After you have started the SSO service, configured Central Administration, and created and encryption key, you must configure account information for the enterprise application definition.
  1. Navigate to the Operations page of Central Administration.
  2. In the Security Configuration section, click the Manage Settings for Single Sign-On link.

  3. Click Manage Settings for Enterprise Application Definitions.