VMware View 4.x Sizing Tool?

I really wished there was some kind of a sizing tool spreadsheet similar to what Microsoft had to offer for their Exchange and OCS/ Lync deployments that make various assumptions to assist you in sizing the a solution.  I’ve been trying to work out estimates for a 300 virtual desktop deployment with limited information on the type of OS, remote workers, screen resolution, type of workers, applications to determine stateful or stateless desktops and so forth.  What I was able to find was the VMware View Architecture Planning View 4.6 guide (www.vmware.com/pdf/view-46-architecture-planning.pdf) so with it, I worked out a spreadsheet to calculate some numbers:


Unfortunately, the planning guide only provides bandwidth allocation for the knowledge worker so I ended up having to work out some estimates for the other types of workers as well.
With all that being said, I am glad that the planning guide is available and through reading it twice over the last two nights gives me the impression that whoever wrote it put a lot of thought into it.  While I do understand that there are seemingly infinite factors that can drastically affect sizing and the best approach is to actually pilot a solution but I still think it would be nice to have some sort of tool that makes a bunch of assumptions and then spits out some numbers with a big footnote saying it’s just to serve as a general guideline.
For those who are used to reading my other posts that are meant to provide a solution to a problem, note that this post is not meant to provide planning guidelines but just a way of speaking my mind towards this exercise.  If there’s a tool available for partners that I’m aware about, please feel free to put a comment below to let me know.

The message: “Active Instance not set. To set an active instance use "Activate Instance ".” is displayed when you attempt to perform an authoritative restore with ntdsutil on a Windows 2008 R1 or R2 domain controller

Problem

The domain controllers in your environment are either Windows Server 2008 R1 or R2 and you’re trying to mark an object or subtree as authoritative so that they will be replicated to the other domain controllers by following the instructions provided in:

Mark an Object or Objects as Authoritative
http://technet.microsoft.com/en-us/library/cc816813(WS.10).aspx

However, you notice that whenever you attempt to mark an object, subtree, or restore the database, you receive the following warning:

Active Instance not set. To set an active instance use "Activate Instance ".

Proceeding with the restore database or restore object or restore subtree will throw the error:

Error parsing Input – Invalid Syntax

Solution

The instructions provided is actually missing an important step where you should execute the following:

activate instance ntds

The following is what the restore is supposed to look like:

C:\Users\Administrator.DC1>ntdsutil

ntdsutil: activate instance ntds

Active instance set to "ntds".

ntdsutil: authoritative restore

authoritative restore: restore subtree "CN=CDP,CN=Public Key Services,CN=Service

s,CN=Configuration,DC=terran,DC=local"

The TechNet article is dated July 15, 2010 and it looks like Microsoft never updated it with the missing step another user pointed out at the bottom so if you run into this issue, execute the missing command prior using the restore command.

How Lync Server 2010 Setup installs and configure the RTCLocal SQL instance on a front-end server of an Enterprise Pool

I had to deploy a Lync Server 2010 Enterprise Pool about a month ago and while I thought it would take just a few hours to complete, it ended up taking a good day and a half.  The problem I ran into was for some odd reason the installation would only create the lis and xds database during the install:

It took me 10 reinstall attempts while cleaning out the settings in the configuration container of Active Directory and uninstalling the binaries to get the databases installed properly.  I took a good few hours performing post mortem on what I did differently but failed to figure out what was the problem.  Although I wasn’t able to figure out what caused my installs to fail, I did learn something about the installation while I was troubleshooting and that was how the databases were created.  Unfortunately, I just realized that I only had the logs for the RTCLocal SQL instance install for the front-end server and since I’m at the JFK airport with no free wireless access, I’ll spend the the time I have as I wait for my next flight to write about the local SQL RTCLocal instance and will retrieve the logs for the actual SQL install at a later time for another post.

The LCSSetup_Commands.txt file

Upon a successful Lync Server 2010 front-end server install, a text file named LCSSetup_Commands.txt actually gets created in the AppData folder of the account that you used to install the front-end server:

C:\Users\someAccountName\AppData\Local\Temp

If we open that log file, we’ll see that it contains a verbose log of the installation:

I won’t paste all the log entries in this post but what I’ll do is copy and paste the ones that are of interest for seeing what actually gets executed to create the databases for the local SQL instance named RTCLocal located on the front-end server.

Browsing through the log will show that the install actually uses the CScript.exe command to execute prewritten .wsf scripts which are copied to the C:\Program Files\Common Files\Microsoft Lync Server 2010\DbSetup folder when you run the Install Local Configuration Store step:

When the installer executes these scripts, parameters are also passed to customize the install for a local SQL install or a back-end server.  The following are the databases and the corresponding scripts that are found in the log file:

rtc

CScript.exe //U //Nologo DBSetup.wsf /sqlserver:localhost\rtclocal /serveracct:"SVR-LYNC-01\RTC Server Local Group;SVR-LYNC-01\RTC Component Local Group" /adminacct:"SVR-LYNC-01\RTC Local Administrators" /roacct:"SVR-LYNC-01\RTC Local Read-only Administrators" /role:se /verbose

--------------------------------------------------------------------------------------------

Installed SQL Server 2005 Backward Compatibility version is 8.05.2312

Connecting to SQL Server on localhost\rtclocal

SqlMajorVersion : 10

SqlMinorVersion : 0

SqlBuildNo : 2531

SQL version is acceptable: 10.0.2531.0

Default database data file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

Default database data file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

Default database log file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

(Database rtcdyn doesn't exist.)

Creating database rtcdyn

    DbFile : PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtcdyn.mdf
    LogFile: PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtcdyn.ldf

Executing resource SetDbOptions on rtcdyn

Executing batch dbcommon.sql on rtcdyn

Executing batch types.sql on rtcdyn

Executing batch roles.sql on rtcdyn

Executing batch dbrtcdyn.sql on rtcdyn

(Database doesn't exist. Performing clean install.)

Creating database rtc

    DbFile : PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtc.mdf
    LogFile: PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtc.ldf

Executing resource SetDbOptions on rtc

Executing batch dbcommon.sql on rtc

Executing batch types.sql on rtc

Executing batch roles.sql on rtc

Executing batch dbrtc.sql on rtc

Executing resource LinkStaticAndDynamicDatabases on rtc

Executing resource DbReIndex on rtc

Setting security in rtc

DbOwner is now sa

SVR-LYNC-01\RTC Component Local Group has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Component Local Group SQL login

Adding SVR-LYNC-01\RTC Component Local Group SQL login

Adding SVR-LYNC-01\RTC Component Local Group db user in rtc

SVR-LYNC-01\RTC Local Administrators has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Local Administrators SQL login

Adding SVR-LYNC-01\RTC Local Administrators SQL login

Adding SVR-LYNC-01\RTC Local Administrators db user in rtc

SVR-LYNC-01\RTC Local Read-only Administrators has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Local Read-only Administrators SQL login

Adding SVR-LYNC-01\RTC Local Read-only Administrators SQL login

Adding SVR-LYNC-01\RTC Local Read-only Administrators db user in rtc

SVR-LYNC-01\RTC Server Local Group has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Server Local Group SQL login

Adding SVR-LYNC-01\RTC Server Local Group SQL login

Adding SVR-LYNC-01\RTC Server Local Group db user in rtc

Adding user SVR-LYNC-01\RTC Server Local Group to role ServerRole

Adding user SVR-LYNC-01\RTC Component Local Group to role ServerRole

Adding user SVR-LYNC-01\RTC Local Read-only Administrators to role ReadOnlyRole

Adding user SVR-LYNC-01\RTC Local Administrators to role AdminRole

Successfully added logins and db users to the specified database roles in rtc

Setting Db schema version to 59

Setting Db sproc version to 35

Setting security in rtcdyn

Opened database rtc

Db owner is sa

Adding SVR-LYNC-01\RTC Component Local Group db user in rtcdyn

DataBaseRole.AddMember succeeded for SVR-LYNC-01\RTC Component Local Group (  )

Adding SVR-LYNC-01\RTC Server Local Group db user in rtcdyn

DataBaseRole.AddMember succeeded for SVR-LYNC-01\RTC Server Local Group (  )

Adding SVR-LYNC-01\RTC Local Administrators db user in rtcdyn

DataBaseRole.AddMember succeeded for SVR-LYNC-01\RTC Local Administrators (  )

Successfully assigned security to rtcdyn from rtc

rtcdyn

CScript.exe //U //Nologo DBSetup.wsf /sqlserver:localhost\rtclocal /serveracct:"SVR-LYNC-01\RTC Server Local Group;SVR-LYNC-01\RTC Component Local Group" /adminacct:"SVR-LYNC-01\RTC Local Administrators" /roacct:"SVR-LYNC-01\RTC Local Read-only Administrators" /role:se /verbose

--------------------------------------------------------------------------------------------

Installed SQL Server 2005 Backward Compatibility version is 8.05.2312

Connecting to SQL Server on localhost\rtclocal

SqlMajorVersion : 10

SqlMinorVersion : 0

SqlBuildNo : 2531

SQL version is acceptable: 10.0.2531.0

Default database data file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

Default database data file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

Default database log file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

(Database rtcdyn doesn't exist.)

Creating database rtcdyn

    DbFile : PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtcdyn.mdf
    LogFile: PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtcdyn.ldf

Executing resource SetDbOptions on rtcdyn

Executing batch dbcommon.sql on rtcdyn

Executing batch types.sql on rtcdyn

Executing batch roles.sql on rtcdyn

Executing batch dbrtcdyn.sql on rtcdyn

(Database doesn't exist. Performing clean install.)

Creating database rtc

    DbFile : PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtc.mdf
    LogFile: PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\rtc.ldf

Executing resource SetDbOptions on rtc

Executing batch dbcommon.sql on rtc

Executing batch types.sql on rtc

Executing batch roles.sql on rtc

Executing batch dbrtc.sql on rtc

Executing resource LinkStaticAndDynamicDatabases on rtc

Executing resource DbReIndex on rtc

Setting security in rtc

DbOwner is now sa

SVR-LYNC-01\RTC Component Local Group has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Component Local Group SQL login

Adding SVR-LYNC-01\RTC Component Local Group SQL login

Adding SVR-LYNC-01\RTC Component Local Group db user in rtc

SVR-LYNC-01\RTC Local Administrators has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Local Administrators SQL login

Adding SVR-LYNC-01\RTC Local Administrators SQL login

Adding SVR-LYNC-01\RTC Local Administrators db user in rtc

SVR-LYNC-01\RTC Local Read-only Administrators has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Local Read-only Administrators SQL login

Adding SVR-LYNC-01\RTC Local Read-only Administrators SQL login

Adding SVR-LYNC-01\RTC Local Read-only Administrators db user in rtc

SVR-LYNC-01\RTC Server Local Group has a Win32_Account instance of SIDType 4

Refreshing existing SVR-LYNC-01\RTC Server Local Group SQL login

Adding SVR-LYNC-01\RTC Server Local Group SQL login

Adding SVR-LYNC-01\RTC Server Local Group db user in rtc

Adding user SVR-LYNC-01\RTC Server Local Group to role ServerRole

Adding user SVR-LYNC-01\RTC Component Local Group to role ServerRole

Adding user SVR-LYNC-01\RTC Local Read-only Administrators to role ReadOnlyRole

Adding user SVR-LYNC-01\RTC Local Administrators to role AdminRole

Successfully added logins and db users to the specified database roles in rtc

Setting Db schema version to 59

Setting Db sproc version to 35

Setting security in rtcdyn

Opened database rtc

Db owner is sa

Adding SVR-LYNC-01\RTC Component Local Group db user in rtcdyn

DataBaseRole.AddMember succeeded for SVR-LYNC-01\RTC Component Local Group (  )

Adding SVR-LYNC-01\RTC Server Local Group db user in rtcdyn

DataBaseRole.AddMember succeeded for SVR-LYNC-01\RTC Server Local Group (  )

Adding SVR-LYNC-01\RTC Local Administrators db user in rtcdyn

DataBaseRole.AddMember succeeded for SVR-LYNC-01\RTC Local Administrators (  )

Successfully assigned security to rtcdyn from rtc

xds

CScript.exe //U //Nologo xdssetup.wsf /clean /publisheracct:"RTC Local Administrators" /replicatoracct:"NT SERVICE\REPLICA;RTC Local Config Replicator" /consumeracct:"RTC Server Local Group;RTC Component Local Group;RTC Local Read-only Administrators" /role:replica /verbose

--------------------------------------------------------------------------------------------

Installed SQL Server 2005 Backward Compatibility version is 8.05.2312

Connecting to SQL Server on SVR-LYNC-01\rtclocal

SqlMajorVersion : 10

SqlMinorVersion : 0

SqlBuildNo : 2531

SQL version is acceptable: 10.0.2531.0

Default database data file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

Default database data file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

Default database log file path is c:\Program Files\Microsoft SQL Server\MSSQL10.RTCLOCAL\MSSQL\Data

(Database xds doesn't exist.)

Creating database xds

    DbFile : PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\xds.mdf
    LogFile: PhysicalName = c:\program files\microsoft sql server\mssql10.rtclocal\mssql\data\xds.ldf

Executing batch dbcommon.sql on xds

Executing resource SetDbRoles on xds

Executing batch xds.sql on xds

Setting replica role

Executing resource SetReplica on xds

Executing resource DbReIndex on xds

Setting security in xds

DbOwner is now sa

NT SERVICE\REPLICA is not a valid SQL login. A SQL login with this name will be created.

NT SERVICE\REPLICA doesn't have a Win32_Account instance

Adding NT SERVICE\REPLICA SQL login

Adding NT SERVICE\REPLICA db user in xds

SVR-LYNC-01\RTC Component Local Group is not a valid SQL login. A SQL login with this name will be created.

SVR-LYNC-01\RTC Component Local Group has a Win32_Account instance of SIDType 4

Adding SVR-LYNC-01\RTC Component Local Group SQL login

Adding SVR-LYNC-01\RTC Component Local Group db user in xds

SVR-LYNC-01\RTC Local Administrators is not a valid SQL login. A SQL login with this name will be created.

SVR-LYNC-01\RTC Local Administrators has a Win32_Account instance of SIDType 4

Adding SVR-LYNC-01\RTC Local Administrators SQL login

Adding SVR-LYNC-01\RTC Local Administrators db user in xds

SVR-LYNC-01\RTC Local Config Replicator is not a valid SQL login. A SQL login with this name will be created.

SVR-LYNC-01\RTC Local Config Replicator has a Win32_Account instance of SIDType 4

Adding SVR-LYNC-01\RTC Local Config Replicator SQL login

Adding SVR-LYNC-01\RTC Local Config Replicator db user in xds

SVR-LYNC-01\RTC Local Read-only Administrators is not a valid SQL login. A SQL login with this name will be created.

SVR-LYNC-01\RTC Local Read-only Administrators has a Win32_Account instance of SIDType 4

Adding SVR-LYNC-01\RTC Local Read-only Administrators SQL login

Adding SVR-LYNC-01\RTC Local Read-only Administrators db user in xds

SVR-LYNC-01\RTC Server Local Group is not a valid SQL login. A SQL login with this name will be created.

SVR-LYNC-01\RTC Server Local Group has a Win32_Account instance of SIDType 4

Adding SVR-LYNC-01\RTC Server Local Group SQL login

Adding SVR-LYNC-01\RTC Server Local Group db user in xds

Adding user SVR-LYNC-01\RTC Local Administrators to role PublisherRole

Adding user SVR-LYNC-01\RTC Server Local Group to role ConsumerRole

Adding user SVR-LYNC-01\RTC Component Local Group to role ConsumerRole

Adding user SVR-LYNC-01\RTC Local Read-only Administrators to role ConsumerRole

Adding user NT SERVICE\REPLICA to role ReplicatorRole

Adding user SVR-LYNC-01\RTC Local Config Replicator to role ReplicatorRole

Adding user NT SERVICE\REPLICA to role PublisherRole

Adding user SVR-LYNC-01\RTC Local Config Replicator to role PublisherRole

Successfully added logins and db users to the specified database roles in xds

Setting Db schema version to 10

Setting Db sproc version to 8

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

There you have it, the scripts and parameters used to install and configure the 3 databases found in the local SQL instance on the front-end server.

A word of caution that although these commands can be used to install the databases for the local instance, I wouldn’t recommend manually installing these databases in any situation.  There is too much room for mistakes and as most of us know, we are all prone to errors.

Publishing a new Lync Server 2010 Standard Edition Server topology throws the error: “Error accessing share \\someServer.someDomain.com–Method failed with unexpected error code 2310..” & “Cannot create directory. The path is read only: \\someserver.someDomain.com\LyncShare\1-ApplicationServer-1\AppServerFiles”

I received a call the other day from an ex-colleague who had some issues with publishing a new Lync Server 2010 Standard Edition Server topology.  The first screen I saw as soon as I got desktop sharing up with him was the following:

The information provided in the window above wasn’t too helpful so I got him to click on the View Logs button to bring up the detailed logs for the topology publisher.  As I scrolled through the logs, I immediately saw the following errors:

Error: Error accessing share \\lyncstd.someDomain.com\LyncShare - Method failed with unexpected error code 2310..

Error: Cannot create directory. The path is read only: \\lyncstd.someDomain.com\LyncShare\1-ApplicationServer-1\AppServerFiles

Error: Cannot create directory. The path is read only: \\lyncstd.someDomain.com\LyncShare\1-ApplicationServer-1\AppServerFiles\CPS

Error: Cannot create directory. The path is read only: \\lyncstd.someDomain.com\LyncShare\1-ApplicationServer-1\AppServerFiles\Rgs

As some of you may probably have guessed, the first question I asked after seeing these errors was whether he had created the LyncShare folder on the server and not surprisingly, he didn’t.  What I ended up doing as I had control of the desktop was create the share on the server and republish the topology so that the sub folders such as 1-Application-1 would automatically created.

“Preparing single Standard Edition Server” throws error: “Prerequisite installation failed: SqlExpressRtc”

I was a bit surprised when I ran into the error Prerequisite installation failed: SqlExpressRtc when running the Preparing single Standard Edition Server step during a Standard Edition Lync Server 2010 install when I figured out what the problem was.

Problem

You’re deploying a Lync Server 2010 Standard Edition server and have gotten to the step where you need to run the step:

Everything appears to proceed as expected through the wizard:

… until you get to the following error:

> BootstrapperLogging status to: C:\Users\tluk\AppData\Local\Temp\2\BootstrapSqlExpress-[2011_05_17][15_44_11].htmlChecking prerequisites for bootstrapper...Checking prerequisite WMIEnabled...prerequisite satisfied.Checking prerequisite NoBootstrapperOnBranchOfficeAppliance...prerequisite satisfied.Checking prerequisite SupportedOS...prerequisite satisfied.Checking prerequisite NoOtherVersionInstalled...prerequisite satisfied.Caching file setup\OcsCore.msiCaching file setup\Server.msiCaching file setup\OcsMcu.msiCaching file setup\ArchService.msiCaching file setup\CAA.msiCaching file setup\CAS.msiCaching file setup\Rgs.msiCaching file setup\CPS.msiCaching file setup\PDP.msiCaching file setup\MgmtServer.msiCaching file setup\MediationServer.msiCaching file setup\Ats.msiCaching file setup\MonitoringServer.msiCaching file setup\AppServer.msiCaching file setup\DataMcu.msiCaching file setup\WebComponents.msiCaching file setup\ReachFonts.msiCaching file setup\AdminTools.msiCaching file vcredist_x64.exeCaching file SQLEXPR_x64.exeCaching file sqlncli.msiCaching file SQLServer2005_BC.msiCaching file Setup\UcmaRuntime.msiCaching file rewrite_2.0_rtw_x64.msiCaching file Setup\ucmaworkflowruntime.msiCaching file Setup\speech\SpeechPlatformRuntime.msiCaching file Setup\speech\ca-ES\MSSpeech_SR_ca-ES_TELE.msiCaching file Setup\speech\ca-ES\MSSpeech_TTS_ca-ES_Herena.msiCaching file Setup\speech\da-DK\MSSpeech_SR_da-DK_TELE.msiCaching file Setup\speech\da-DK\MSSpeech_TTS_da-DK_Helle.msiCaching file Setup\speech\de-DE\MSSpeech_SR_de-DE_TELE.msiCaching file Setup\speech\de-DE\MSSpeech_TTS_de-DE_Hedda.msiCaching file Setup\speech\en-AU\MSSpeech_SR_en-AU_TELE.msiCaching file Setup\speech\en-AU\MSSpeech_TTS_en-AU_Hayley.msiCaching file Setup\speech\en-CA\MSSpeech_SR_en-CA_TELE.msiCaching file Setup\speech\en-CA\MSSpeech_TTS_en-CA_Heather.msiCaching file Setup\speech\en-GB\MSSpeech_SR_en-GB_TELE.msiCaching file Setup\speech\en-GB\MSSpeech_TTS_en-GB_Hazel.msiCaching file Setup\speech\en-IN\MSSpeech_SR_en-IN_TELE.msiCaching file Setup\speech\en-IN\MSSpeech_TTS_en-IN_Heera.msiCaching file Setup\speech\en-US\MSSpeech_SR_en-US_TELE.msiCaching file Setup\speech\en-US\MSSpeech_TTS_en-US_Helen.msiCaching file Setup\speech\es-ES\MSSpeech_SR_es-ES_TELE.msiCaching file Setup\speech\es-ES\MSSpeech_TTS_es-ES_Helena.msiCaching file Setup\speech\es-MX\MSSpeech_SR_es-MX_TELE.msiCaching file Setup\speech\es-MX\MSSpeech_TTS_es-MX_Hilda.msiCaching file Setup\speech\fi-FI\MSSpeech_SR_fi-FI_TELE.msiCaching file Setup\speech\fi-FI\MSSpeech_TTS_fi-FI_Heidi.msiCaching file Setup\speech\fr-CA\MSSpeech_SR_fr-CA_TELE.msiCaching file Setup\speech\fr-CA\MSSpeech_TTS_fr-CA_Harmonie.msiCaching file Setup\speech\fr-FR\MSSpeech_SR_fr-FR_TELE.msiCaching file Setup\speech\fr-FR\MSSpeech_TTS_fr-FR_Hortense.msiCaching file Setup\speech\it-IT\MSSpeech_SR_it-IT_TELE.msiCaching file Setup\speech\it-IT\MSSpeech_TTS_it-IT_Lucia.msiCaching file Setup\speech\ja-JP\MSSpeech_SR_ja-JP_TELE.msiCaching file Setup\speech\ja-JP\MSSpeech_TTS_ja-JP_Haruka.msiCaching file Setup\speech\ko-KR\MSSpeech_SR_ko-KR_TELE.msiCaching file Setup\speech\ko-KR\MSSpeech_TTS_ko-KR_Heami.msiCaching file Setup\speech\nb-NO\MSSpeech_SR_nb-NO_TELE.msiCaching file Setup\speech\nb-NO\MSSpeech_TTS_nb-NO_Hulda.msiCaching file Setup\speech\nl-NL\MSSpeech_SR_nl-NL_TELE.msiCaching file Setup\speech\nl-NL\MSSpeech_TTS_nl-NL_Hanna.msiCaching file Setup\speech\pl-PL\MSSpeech_SR_pl-PL_TELE.msiCaching file Setup\speech\pl-PL\MSSpeech_TTS_pl-PL_Paulina.msiCaching file Setup\speech\pt-BR\MSSpeech_SR_pt-BR_TELE.msiCaching file Setup\speech\pt-BR\MSSpeech_TTS_pt-BR_Heloisa.msiCaching file Setup\speech\pt-PT\MSSpeech_SR_pt-PT_TELE.msiCaching file Setup\speech\pt-PT\MSSpeech_TTS_pt-PT_Helia.msiCaching file Setup\speech\ru-RU\MSSpeech_SR_ru-RU_TELE.msiCaching file Setup\speech\ru-RU\MSSpeech_TTS_ru-RU_Elena.msiCaching file Setup\speech\sv-SE\MSSpeech_SR_sv-SE_TELE.msiCaching file Setup\speech\sv-SE\MSSpeech_TTS_sv-SE_Hedvig.msiCaching file Setup\speech\zh-CN\MSSpeech_SR_zh-CN_TELE.msiCaching file Setup\speech\zh-CN\MSSpeech_TTS_zh-CN_HuiHui.msiCaching file Setup\speech\zh-HK\MSSpeech_SR_zh-HK_TELE.msiCaching file Setup\speech\zh-HK\MSSpeech_TTS_zh-HK_HunYee.msiCaching file Setup\speech\zh-TW\MSSpeech_SR_zh-TW_TELE.msiCaching file Setup\speech\zh-TW\MSSpeech_TTS_zh-TW_HanHan.msiCaching file vj2se_x64.exeChecking prerequisites for roles...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...successChecking prerequisite SqlBackcompat...prerequisite satisfied.Checking prerequisite UcmaRedist...prerequisite satisfied.

Checking prerequisite SqlExpressRtc...installing...failure code –1

Prerequisite installation failed: SqlExpressRtc

Clicking on the View Log button shows the following:

Error: Prerequisite installation failed: SqlExpressRtc
▼ Details

└ Type: PrereqInstallFailed
└ ▼ Stack Trace

└     at Microsoft.Rtc.Internal.Tools.Bootstrapper.BootstrapperTask.AddMsiPrereq(String prereqName)
at Microsoft.Rtc.Management.Internal.Utilities.LogWriter.InvokeAndLog[T](Action`1 action, T arg)

        5/17/2011 3:45:34 PM        Error

Executing external command: C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\SQLEXPR_x64.exe /Q /HIDECONSOLE /ACTION=Install /FEATURES=SQLEngine,Tools /INSTANCENAME=RTC /TCPENABLED=1 /SQLSVCACCOUNT="NT AUTHORITY\NetworkService" /SQLSYSADMINACCOUNTS="Builtin\Administrators" /BROWSERSVCSTARTUPTYPE="Automatic" /AGTSVCACCOUNT="NT AUTHORITY\NetworkService" /SQLSVCSTARTUPTYPE=Automatic

At this point, you can actually go ahead and execute the command shown above with the switches to manually install the SQL Express instance for the Standard Edition Lync Server but I was curious as to why it would fail and my first hunch was to try running setup.exe as an administrator:

Once I ran the install as an administrator, I noticed that the installation of the local SQL instance successfully starts:

 

I believe the last time I encountered such a problem was back in the days when Exchange 2007 had just come out and I was installing it on a Windows Server 2008 R1 server where the setup would always fail until I open up a command prompt as administrator to run setup.  Strange that I’m encountering this now as I don’t recall doing so in the past.  The only difference between this deployment was that the operating system and software used is:

1. Windows Server 2008 R2 64-bit with SP1

2. Lync Server 2010

Hope this helps anyone who may run into this problem a quick answer through a simple Google search.

Publishing Lync Server 2010 Standard Edition topology fails at: “Creating Central Management Store”

Before I begin writing about this problem, understand that this problem can be caused by many reasons and the reason written in this post is only one of them.

Problem

You’ve completed going through the new topology wizard in Topology Builder and proceed to publish the topology but get the following error:

Step: Creating Central Management Store

Status: Failure

Clicking on the View Logs button shows the following content in the log file:

Error: Error connecting to "lyncstd.domain.com\rtc" while installing "CentralMgmtStore". Verify that the SQL instance is running, connections are not being blocked by a firewall, and that you have SQL administrator permissions. For details, see the following log file: "C:\Users\tluk\AppData\Local\Temp\2\Create-CentralMgmtStore-lyncstd.domain.com_rtc-[2011_05_17][15_38_22].log"        5/17/2011 3:39:23 PM        Error

Error: An error occurred: "Microsoft.Rtc.Common.Data.SqlConnectionException" "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"        5/17/2011 3:39:39 PM        Error

Solution

As I mentioned earlier, this can be caused by many issues but most of the time it’s because the topology publisher cannot contact the backend SQL server.  When I was called about this problem, the first question I asked was whether SQL was installed yet and as it turns out, the Prepare first Standard Edition Server step wasn’t ran yet and this step is where the installer creates the local SQL instance for a Lync Server 2010 Standard Edition server. 

Once I got the administrator to run this step, the topology published without any issues.

OCS 2007 R1 or R2 MOC client indicates the following error: “Communicator could not retrieve calendar Out of Office information from Exchange Web Services…”

It’s been a while since I’ve come across an OCS 2007 R1 environment but as I start off a new project at a client’s office today, I realized that they were still on R1.  As I took the time to familiarize the RCC configuration they have in place with their Avaya PBX, we noticed that some users who have recently been migrated from Exchange 2007 to 2010 experience the following when they log into their MOC client:

When I click on the error to bring up the details, I would get the following message:

Communicator could not retrieve calendar or Out of Office information from Exchange Web Services. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.

When I saw this error, I immediately had the hunch that it had to do with a combination of their EWS URL and certificate because I’ve come across something similar in the past which I blogged about here:

OCS 2007 MOC OOF Information reliance on Exchange CAS Server
http://terenceluk.blogspot.com/2010/07/ocs-2007-moc-oof-information-reliance.html

The first troubleshooting step I tried was to open up Internet Explorer and navigate to the internal link of the InternalURL attribute (retrieved via the cmdlet Get-WebServicesVirtualDirectory) of their EWS directory which showed that the link which was published as https://webmail.domain.com/EWS/Exchange.asmx had a certificate that contained this URL as the common name.  What’s interesting about the information I saw was that they had a different internal and external domain name and that they had their public domain configured as a zone in their internal DNS.  What basically happens is that their internal Outlook clients will query for the IP of webmail.domain.com and would get an internal IP since the reply would be from their internal DNS.  This obviously wasn’t an unsupported setup so I continued on with the troubleshooting.

After taking a deeper look at the output from Get-WebServicesVirtualDirectory | FL, I noticed the following:

[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory | fl

RunspaceId                      : b47c36a9-2464-4e39-9d6b-7988c0f5abcb
CertificateAuthentication       :
InternalNLBBypassUrl            : https://cas1.domain.local/ews/exchange.asmx
GzipLevel                       : High
Name                            : EWS (Default Web Site)
InternalAuthenticationMethods   : {Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods   : {Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication      : False
WSSecurityAuthentication        : True
LiveIdBasicAuthentication       : False
BasicAuthentication             : False
DigestAuthentication            : False
WindowsAuthentication           : True
MetabasePath                    : IIS://EXCHANGE.domain.com/W3SVC/1/ROOT/EWS
Path                            : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
Server                          : EXCHANGE
InternalUrl                     : https://webmail.domain.com/EWS/Exchange.asmx
ExternalUrl                     : https://webmail.domain.com/ews/exchange.asmx
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName               : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=EXCHANGE,CN=Servers,CN=Exchange Adm
                                  inistrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=SomeCompany,CN=Micros
                                  oft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local
Identity                        : EXCHANGE\EWS (Default Web Site)
Guid                            : 1952de93-5772-449e-8813-70ff150973b0
ObjectCategory                  : domain.com/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchWebServicesVirtualDirectory}
WhenChanged                     : 8/13/2010 2:19:39 PM
WhenCreated                     : 8/13/2010 2:19:38 PM
WhenChangedUTC                  : 8/13/2010 5:19:39 PM
WhenCreatedUTC                  : 8/13/2010 5:19:38 PM
OrganizationId                  :
OriginatingServer               : dc1.domain.com
IsValid                         : True

What caught my attention was the line:

InternalNLBBypassUrl            : https://cas1.domain.local/ews/exchange.asmx

A quick search on Google shows the following:

http://technet.microsoft.com/en-us/library/aa997233.aspx

The InternalNLBBypassUrl parameter specifies the URL of the Client Access server, regardless of whether it's behind a Network Load Balancing (NLB) array. Although the InternalUrl parameter is set to the URL of the NLB array, the InternalNLBBypassUrl parameter should always be set to the URL of the Client Access server. This is because certain Exchange Web Services calls require machine affinity, and Exchange Web Services proxy incoming calls to a more appropriate Client Access server whenever possible.

The explanation from the TechNet site pretty much states we shouldn’t be changing this URL to the public URL as we did with the other attributes.  Since the certificate they were using was from a public CA, what I ended up doing just as a test was issue a certificate from their internal CA that included the internal URL of their CAS server, reassigned it within IIS for the virtual directory, rebooted the server and the error on the MOC client went away.  Note that I also tried restarting IIS and the CAS RPC service but it did not correct the problem but a reboot did.

Not that I think I’ll be dealing with many more OCS 2007 R1 or R2 deployments but this was a good refresher.  Hope this helps anyone out there that may experience this problem.

Moving VMware vCenter from one ESXi host to another when using Nexus 1000v or Distributed Virtual Switch (DVS) Switches

I’ve long had a love and hate feeling towards VMware’s new distributed virtual switches ever since it was made available.  For those who have come across one of my posts from last year:

UCS & vCenter’s dvSwitches: One issue leads to another
http://terenceluk.blogspot.com/2010/07/ucs-vcenters-dvswitches-one-issue-leads.html

… would know that I had quite the bad experience with them during a one of my deployments.  So just a month ago during a VMware and Cisco UCS deployment, I had to move vCenter from Cisco UCS blade that was going to be removed from the chassis over to one of the blades that was there to stay.  The challenge I faced was that my practice lead had already deployed the Nexus 1000v on all of the other hosts with the VEMs installed.  The blade that ran vCenter was only using a regular vSwitch and had vCenter on the local storage.  The best option in this case was to push the VEM over to this temporary host, flip the physical NICs over to the Nexus 1000v and then copy the virtual machine over.  However, I didn’t really think this through at the beginning and had already copied the virtual machine over to the shared storage ready to mount and bring it up.  Due to the tight timeline of getting my list of tasks to be completed, I didn’t want to go back, push the VEM and start the copy again.  In hindsight, I’m sure I may have been able to edit the VMX file to manually enter a Nexus 1000v port group or if there were additional NICs available, to create a regular vSwitch, but since I only had a few minutes to get this up so I had to think fast.  While the following workaround isn’t exactly the best solution if I had thought it through, it does serve as a way of getting around this in situations such as mine or if there are other reasons why you can’t push the VEM out.

Problem

You’ve successfully copied vCenter from the local storage of a server over to shared storage and inventoried the virtual machine onto the new server with Nexus 1000v VEM installed and no regular vSwitches.  However, as soon as you try to configure the network interface’s port group, you find that you have no option of selecting the Nexus 1000v port groups because your vCenter is down:

Solution

What I ended up doing was rename the newly mounted vCenter with “-1” at the end so that we won’t have any name conflicts:

Powered up the vCenter on the old host:

Now that the old vCenter was up, we can now choose the port groups provided by the Nexus 1000v on the vCenter that was copied to the new host and shared storage:

1. Now that we have the right Nexus 1000v port group selected, we can proceed with:

2. Connect to the ESXi host that has the the old vCenter mounted.

3. Shutdown the old vCenter.

4. Remove the old vCenter from inventory.

5. Connect directly to the new host that has the new vCenter on shared storage.

6. Rename the vCenter logical name to remove the “-1”.

7. Power up the new vCenter.

8. Connect to the new vCenter via vSphere Client.

9. Rename the logical name once again as you can in see in the following screenshot that it has a “(1)” appended to it due to a name conflict.

10. Remove the orphaned entry of the old vCenter:

… and we’re done.  Again, this is probably not the best solution nor is it the only way to accomplish the same goal but if you’re pressed for time and need to get the vCenter up immediately, this is definitely a viable solution.

Cisco UCS B-Series Infrastructure IOM (FEX) Modules throw the major error: “IOM 1/x (a or b) current connectivity does not match discovery policy: unsupported-connectivity”

I was asked while ago to look at why a new Cisco UCS B-Series Infrastructure environment was lighting up like a Christmas tree.  Eager to look at what the reason why, I logged on and long behold this is what I saw:

As shown in the screenshot above, it’s obvious that all of the IO modules listed indeed have errors but what may not be as obvious through looking at it initially is that all of the chassis either had their first or second IOMs on the 5108 chassis missing.  Have another look again at the screenshot and you’ll notice that none of the 2 IOMs.

Before I proceeded to look at why only 1 IOM was showing up for each chassis, I went ahead to try and fix the first one by re-acknowledging the chassis 1:

Once the discovery process completed, the errors cleared for IOM 1 on the chassis:

What I also realized was when the re-acknowledging of the chassis completed, the missing IOM began showing up but all were highlighted with a major fault.  A bit more browsing around revealed the following on the 6120s:

Fabric A

Fabric B

I know it’s probably not easy to notice what I’m seeing because you don’t know the connections so let me begin by explaining that the way the IOMs were plugged into the Fabrics was:

Port 1 and 2 on Fabric A –> IOM 1 Chassis 1

Port 3 and 4 on Fabric A –> IOM 1 Chassis 1

…

… and …

Port 1 and 2 on Fabric B –> IOM 1 Chassis 2

Port 3 and 4 on Fabric B –> IOM 1 Chassis 2

 

By reviewing ports on the fabric interconnects, the pattern I saw was that the ports with faults were the ones that were connected to the IOMs that were previously missing on the chassis’ listed in UCS Manager.  Now that I knew there was a problem with the connections, I went ahead to dig into the events of the missing IOMs that  showed up after a re-acknowledge operation on the chassis and saw the following error:

Configuration State: unsupported-connectivity

Overall Status: fabric-unsupported-conn

Clicking on the fault showed the following details of the error:

Affected object: sys/chassis-1/slot-2

Description: IOM 1/2 (B) current connectivity does not match discovery policy: unsupported-onnectivity

ID: 415387

Cause: unsupported-connectivity-configuration

Code: F0401

Original severity: major

Previous severity: major

I had a hunch immediately after I read the error and that was to check the Chassis Discovery Policy and just as suspected, it was set to 2-link but I knew the environment was short of cables (it’s a new setup) and that the 2nd cable was not plugged in:

Once I changed the Chassis Discovery Policy to 1-link:

… then initiated another re-acknowledge of the chassis:

… the error went away:

So to summarize the problem, this was simply a case of specifying a Chassis Discovery Policy to a value more than the amount of links currently connected.  There has actually been a debate on what the best practice is and I have done some tests myself but will write another blog post on it when I have more time.

Creating a “Home Folder” in Active Directory at the root of a Windows file server throws the error: “The home folder could not be created because: The network name cannot be found.”

It’s been awhile since I’ve had to do a greenfield deployment of Active Directory as most of the projects I’ve done in the past few years involve established networks so simple setup principals I used to remember back when I originally studied for my MCSE are faint in memory.  With this in mind, I was recently asked to create a few new users for a client and as I went into the Profile tab to enter in a home folder share, I was quickly presented with the following error message when I clicked the OK button:

The home folder could not be created because: The network name cannot be found.

Having not done this for awhile, I started reviewing the profile path setting as shown here:

\\fileprint\adminterence$

Note: Excuse the actual adminterence$ name I used in the example above because what I actually used was %username% but because I forgot to do a screenshot, I used the one I had.

Don’t ask me why but this standard was in there before I got here so I was just simply copying the settings.  What I noticed was that I could actually manually create the share folder first, assign the proper permissions then configure it in the screen above and I would be able to proceed.

After thinking it through for a bit, I had a hunch that perhaps specifying a folder that’s in the root of the server may be my problem so for my next attempt, I specified the following path:

\\fileprint\staff\%username%

Once I put in a top level folder, the configuration would proceed without any error messages.  I haven’t had a chance to test whether it was because:

1. It was a top level folder

2. It had a $ sign at the end so that it would be hidden

… so it could be either or.  I don’t recall ever creating shares at the top level in the past which would explain why I’ve never come across this problem.  Hope this serves to provide a quick answer for anyone who might experience the same problem.  I typically create a folder named users or userprofiles and share that folder out.