Lync Server 2010 Deployment – Part 3

Update:  This process is identical to (and has been tested with) the public release version of Lync Server 2010.
The next step is to enable a few existing user Active Directory accounts for Lync so that client connections can be tested to the Standard Edition Front End server.  Notice that ‘existing users’ was stated as the Lync Control Panel can only enable AD user accounts and not create new user accounts; that must first be performed using Active Directory for Users and Computers (ADUC) or whatever similar tool is desired.

• On the Lync Control Panel select Users and then Enable Users.  Search for the first user account to enable (e.g. Jeff) Select a different user account than the one currently used to logon the Lync Server as an ‘insufficient rights’ error will be returned if an attempt is made to enable the current account.  Assign the user to the single pool in the environment and then generate the SIP address using the desired format (e.g. <SAMAccountName>@csvmp.net).  Leave the Telephony and other policies at the default setting for now, these setting will be modified later on.
• Enable additional accounts now so that this test user account will have at least one other account to contact within the Lync client.

• Sign-in to two separate clients with any of the new accounts and enter the names of the other accounts in the search bar.  Depending on if the previous address book files were downloaded or are still in the process then no results should appear, returning either “No results found” (address book was downloaded but no name was match found) or “The address book is preparing to synchronize”.

    

• Manually update the address book files using the process detailed in this previous article.

Now all standard modalities should be available between the clients, including IM/Presence, conferencing, and application sharing.  The next step is to enable these users for Enterprise Voice (EV) and then configure the Voice features in Lync Server so that not only will Communicator calls be available between them but also Enterprise Voice calling.

Enabling Enterprise Voice

Configuring Enterprise Voice is basically the same steps as it was in OCS but some of he individual steps are handled differently in Lync Server.  For example the OCS Location Profile has been replaced with a Dial Plan in Lync which is an expanded scope that is not just a global definition now but can also be assigned at the user, pool, or site level as well.
For the purposes of this lab a single site will be defined (Chicago) and a single block of telephone numbers will be dedicated to internal Lync users (312-555-75xx).  As usual a fully RFC3966 compliant numbering pattern will be used throughout the Lync and Active Directory fields and a basic 4-digit extension pattern will be added to allow for easy 4-digit dialing.

• Start off by setting the desired phone numbers on each AD user object in the Telephone Number field (telephoneNumber attribute).  Two different formats are shown in the example below.

Regarding the format used for the phone numbers there are two ways this can be approached.  The easiest solution which requires no additional configuration is to populate the numbers directly into RFC3966 format as in             +13125557500      .  Lync will display these by default as they require no normalization.  But if a more common display format of             (312) 555-7500       is used then these numbers will not be normalized by Lync for contacts and require additional configuration of the Address Book service to be displayed in the Lync client.  See this previous blog article for more details on this process.

• Manually update the address book files using the process detailed in this previous article.

And in keeping with the running theme of pointing out differences between OCS and Lync another beneficial change can be seen at this point.  In OCS the was no default EV configuration; no location profile, no route, no normalization rules. They all had to be created from scratch.  But in Lync Server the Voice Routing section of the Control Panel will show that number of default configuration object are already defined: a default global dial plan (Global), a default route (Localroute), etc.
So instead of creating all these objects only some minor changes will be applied to customize them for the desired numbering plan.
A logical place to start out would be the dial plan, which will be customized with two new normalization rules.

• On the existing Global dial plan create a New Normalization Rule which will be used to properly handle many different formats of 10 and 11 digit strings.  This pattern is discussed in detail in one of my older OCS articles.

\+?[\s()\-\./]*1?[\s()\-\./]*\(?\s*([2-9]\d\d)\s*\)?[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)[\s]*
+1$1$2$3

• Add another New Normalization Rule which will be used to support direct dial of 4-digit extensions in the 7500-7599 range.  This simple pattern will match against any 4-digit string starting with 75 and then translate it into a normalized RFC3966 pattern (+E.164).

^(75\d{2})$
+1312555$1

• Remove the default Prefix All rule and reorder the new rules so that the Extension Dialing rule is at the top.  This will not impact the functionality at this point as the only two records are mutually exclusive and do not overlap. But as a habit more specific records should be placed towards the top of the rules list and more generic rules should be towards the bottom.

• Save the changes to the Global dial plan and then Commit All changes.

Now a couple of the Lync-enabled user account need to be enabled for Enterprise Voice as well since all enabled accounts were previously only configured for PC-to-PC Communications.

• Search for and edit the properties of the two primary test accounts in the Lync Control Panel under Users.  Select Enterprise Voice for the Telephony setting and enter the user’s telephone number using the proper Line URI format.  Commit the changes to each user (e.g. tel:            +13125557501      ).

    

• Sign-out and back into both Lync clients with the two updated test accounts and the first indication of the change should be the addition of the Call Forwarding menu at the bottom of the Lync client.

• To test Enterprise Voice calling for internal users as well as the extension-specific normalization pattern enter a 4-digit extension into the search bar and notice that both the normalized number and the resolved internal user are returned in the results.

    

Now would be a good time to define a phone number for the Conferencing Attendant, which can be performed using the Control Panel and is similar to the configuration used by OCS.  But before a Dial-In Access Number can be created a region must first be defined.

• Edit the Global Dial Plan under Voice Routing and enter a descriptive name for the Dial-In Conferencing Region (e.g. Chicago).  Then Commit All changes to apply the change to Lync Server.

• Under the Conferencing options select Dial-In Access Number and create a new entry, using a unique Line URI and SIP URI.  The Display Name and Display Number will be displayed on the Lync contact for this number.

Display Number

(312) 555-7555

Display Name

Conference Bridge

Line URI

tel:            +13125557555

SIP URI

sip:confbridge@csmvp.net

Pool

lab1ls.csmvp.net

• Add an Associated Region and select the region created in the previous step (e.g. Chicago).

• Manually update the address book files using the process detailed in this previous article.
• Search for 7555 from the Lync client to show the new contact object (it is normal for it to appear Offline as the presence is not active on contact objects).

Deploying a Media Gateway

As this walkthrough is meant primarily for test usage in a lab this media gateway will be configured in a unique, yet applicable scenario.  As SIP Trunking becomes more common (which may be addressed in a future article) media gateways will be used less for a default route to the PSTN and more often to bridge Lync Server to an existing legacy PBX system.  So in this lab the routing configuration will be sending only calls to numbers in the r(312) 555-77xx range.  Later on a SIP Trunk will be configured with a default route to handle any calls outside of the defined 75xx and 77xx ranges.
A step which was skipped during the initial deployment in Part 1 must first be addressed: specifying a PSTN gateway. In my lab there is a NET Tenor AF configured on 192.168.207.5 and the Lync Topology must now be updated to reflect this.

• Launch the Topology Builder , download the topology from the existing deployment, and then save the latest configuration data to a .tbxml file.
• Locate PSTN Gateways and select the action to create  a New IP/PSTN Gateway and enter the IP address of the desired media gateway, changing the default port and protocol options to allow for TCP connections to the default listening port on the media gateway of TCP 5060. Normally a secured (certificate-based) TLS connection would be used and is recommended for all production deployments, but for the purposes of this article and the lab a TCP connection is used. Also some older media gateways do no have the ability to have certificates imported on them and thus cannot supported TLS connections.

• Edit the properties of the existing Mediation Pool and select Enable TCP Port on the Mediation Server and leave the default TCP port of 5068 which is the where the Mediation Server will listen for incoming TCP connections for the media gateway.

• Also click Add to associate the Mediation Server with the newly defined PSTN Gateway.

• Publish the topology to apply the changes for the Mediation Server configuration to the Lync environment.

• Modify the Global Voice Policy and create a new PSTN Usage Record (e.g. TenorAF), and add a new Associated Route using the setting in the following section.

Name

Analog Phones

Description

Routes calls to 77xx numbers to internal analog phones.

Match this Pattern

^\+131255577

Associated Gateways

PstnGateway:192.168.207.5

• Enter a sample telephone number (in it’s normalized end-state) within the route’s defined range to test the pattern match.

• Apply and Commit All changes.

At this point +E.164 numbers in the +131255577xx range will be routed to the Tenor gateway but the normalization rules will need to be updated to allow for 4-digit dialing of these numbers within Lync (e.g. 7701).  The simplest approach may seem to be to just create a new normalization rule to handle (7700-7799) digits, but because the internal Lync numbering plan is so similar (7500-7599) then the existing rule can be slightly tweaked to handle both ranges.

• In the Global dial plan edit the Extension Dialing normalization rule and edit the pattern.  Replace the 5 with [5,7] which will expand this regex rule to apply to both 75xx and 77xx (but not include 76xx) as the comma means to match either 5 or 7.

^(7[5,7]\d{2})$

• Commit the changes and tests both 75xx and 77xx extensions from the Lync client (a restart of the client may be required if testing immediately).

Well, that wraps up Part 3 of this series and nearly every feature on Lync Server has been activated for use.  Upcoming articles may focus on configuring Conferencing features, deploying currently available Lync Phone Edition devices (e.g. CX700/Tanjay), and finally Edge Server deployment to allow external access to all these features.  Exchange Integration for UM and IM features will also be covered.

http://blog.schertz.name

 

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.

• 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.

• 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.

• Some of the newly added database files for the pool can be seen in the default SQL Server DATA directory as well.

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.

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.

• 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.

• The other noticeable difference is the amount of new Application Pool defined, as well as the separate internal and external web sites.

 

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.

• 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.

 

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.

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.

 

• 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.

• 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.)

• (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).

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.)

• 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.

 

• 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.

• 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.

• Also locate and launch the SQL Server Configuration Manager to verify the local SQL services are properly installed and running.

• The newly installed SQL Server Express instance default database files can be found in the following default location:

• 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.

• 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.

    

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.

• 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.

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.

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.

 

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.

 

• 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

• 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.

• The raw database files can be found on the Lync Server in the default installation directory shown below.

• Additionally the manually defined file share is now populated with new folder structure.

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

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

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

Bài tiếp theo: Tổng quan về Lotus Domino Server

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:

• Microsoft Baseline Security Analyzer phải được chạy thường xuyên để kiểm tra hệ thống và kiểm tra các bản cập nhật
• Các bản vá lỗi phải được cập nhật cho Windows, IIS và .NET Framework.
• Đăng ký nhận tin với Microsoft Security Notification Service tại :
  http://www.microsoft.com/technet/sec...tin/notify.asp

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ệ