Поделиться через

How to automate Lync Client 2010 deployment in multi architect environment using Active Directory Group Policy

  • Статья

The Lync server 2010 client is a single unified communication client that replaces previously released Office Communicator and Live meeting client, single client performs all the functions of the previous clients including instant messaging (IM), web conferencing, white boarding, desktop sharing, and enterprise voice.

There are two versions of the Lync 2010 client, one for x86 and one for x64 operating systems.  The difference is the bootloader and the prerequisite software included in the client installer (Microsoft Visual C++ 2008 Redistributable - x86 or x64 and SilverLight).  If you try to deploy the x86 version of the client on an x64 computer (or vice versa), you will get an error message. "Installer is not supported on your computer, please use the 64-bit installer to complete the installation.

NOTE:The online meeting Add-On will match the 32bit or 64bit version of version of Office 2007/2010 installed, regardless of the Lync client architecture installed.

It is not uncommon in todays world that there are multi architecture clients (x86 and x64) running in the environment, and it is possible that you dont have any software or tool available to automate the software distribution with right set of bits to the clients, and it can be bit difficult to automate the software distribution using Group Policy as well, The rest of the document will demostrate how we can deploy Lync client 2010 in multi architecture environment using a simple batch file and GPO toghether

I will break this complete process in three parts, to make it look easy and undrestandable

1.  Preparing the environment

2.  Configure GPO to deploy the login script on client machines

3.  Deploy the software bits on the client via the configured login script.

Note: Installation of the client software would require a user to have administrator rights on the local machines, for that reason we will use computer startup script to deploy the software as the software will be installed using local system account which by default has permissions

Preparing the Environment

As there are Windows XP, Windows Vista and Windows 7 clients in both X86 architecture and X64 architecture, we need to ensure that the right bits are installed on the clients, so we need to make the right bits available to clients.

  • Create a file Share on your file server or any other server which is accessible from the network and users can communicate with, for example your file server “FileServer1” and name the folder and file share as “Client_Software_bits”
  • Share the folder and give everyone read permissions on the share to ensure all users can read for this share
  • Create two folders inside the folder create in step 1 and name them as Lync2010 and Office365
  • Create two folders inside each of the above new folders and name them X86 and X64 respectively
  • Now we will have a UNC path like
    • \\FileServer1\Client_Software_bits\Lync2010\X86
    • \\FileServer1\Client_Software_bits\Lync2010\X64
  • Now though we have all the four UNC paths created and available for clients to access, copy the correct platform to the respective version of client software into the folders, X86 bit of client software to X86 folder and X64 bit of client software to X64 folder

Software Bits/Architecture

File Name

Lync 2010 Client/x86

LyncSetup32.EXE

Lync 2010 Client/64-bit

LyncSetup64.EXE
  • Check the file name for the client software, it might look like LyncSetupx86 or LyncSetupX64, rename the files to LyncSetup in both the folders to have common file name which will be used in script
  • Test to access the shares from one of the client machines to ensure you are able to see the files in these folders
  • The script also fires the results of the installation onto a file; in order for that to happen, an additional file share is required which must be accessible by all users and users must have create/write access which can be used to centrally track the installation success
  • In the same file share, create a folder named "Client_deployment_results" on the file server and share the folder with everyone or to be more specific share the folder with Domain users and Domain Computers groups and assign “Create and Modify” permissions to “Domain Users” and "Domain Computers" groups
  • The UNC path for the results folder would look like \\FileServer1\Client_Deployment_Results

Understanding the Login Script

The script is broken into 3 parts,

  • This part of the scripts sets a condition about which platform (Architecture) software to install x86 or x64 and if the software is already installed exit the script

If Exist %systemroot%\%computername%.txt goto END
If Exist "C:\Program Files (x86)\" goto X64

Set ARCHITECTURE=x86

This part of the login script automates the creation of the respective folders under the user’s profile in the desktop

REM Creating Lync and office suite Client folder on %USERPROFILE%
IF NOT EXIST "%USERPROFILE%\Lync_Client\X86" MKDIR "%USERPROFILE%\Lync_Client\X86"

Note: Since we are using computer startup GPO to apply the script on the client machines %userprofile% refers to directory “C:\windows\system32\Config\systemprofile” on windows 7 machines and on windows Xp machines %userprofile% refers to the logged in users profile "Documents and Settings\Users", to manually check whether software bits are copied you need to check the respective directory as per your operating system

  • This part of the script copies the required installation files into the folders created from the previous step.

REM Copying Lync software to Lync Software folder on %USERPROFILE%
pushd "\\fileserver1\Lync2010\Lync_Software\x86\"
XCOPY "*.exe" "%USERPROFILE%\Lync_Client\X86" /I /Y /Q

  • This part of the script will setup the Lync2010 and Office365 suite silently and end user would not experience any GUI or any interferences.

Note: End users should still be informed that their computer is going to have a change so that users aren’t surprised to see the Lync, Silverlight, Visual C++ Distribution installed in their machine. Silverlight and Visual C++ distribution are pre-requisites for Lync2010 client and are installed automatically by LyncSetup.exe

"%UserProfile%\Lync_Client\%ARCHITECTURE%\LyncSetup.exe" /install /silent /fulluisuppression
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% > %systemroot%\%Computername%.txt
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% >\\fileserver1\Client_Deployment_Results\%computername%.txt

  • The Login Script will first of all set the architecture to X86 and then check on the system if “C:\Program Files (X86)” exist, as this folder is available only on 64-bit machines with 64-bit operating system, if the condition is true then the script will set the architecture to x64, and then run the setup locally from the folders we created in first part of the script, Since we have set the architecture to either x86 or x64 and we are using variable %Architecture% in the command line to ensure the right bit of software is run, after the Lync2010 is immediately office 365 suite software will be installed.
  • X64 bit portion of the script will follow the same process as above

:X64

If NOT EXIST "C:\Program Files (x86)\" goto END

Set ARCHITECTURE=x64

REM Creating Lync Client folder on %USERPROFILE%
IF NOT EXIST "%USERPROFILE%\Lync_Client\X64" MKDIR "%USERPROFILE%\Lync_Client\X64"
REM Copying Lync software to Lync Software folder on %USERPROFILE%
pushd "\\fileserver1\Lync2010\Lync_Software\x64\"
XCOPY "*.exe" "%USERPROFILE%\Lync_Client\X64" /I /Y /Q
"%UserProfile%\Lync_Client\%ARCHITECTURE%\LyncSetup.exe" /install /silent /fulluisuppression
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% > %systemroot%\%Computername%.txt
Echo "Lync and Office clients Successfully installed" on %COMPUTERNAME% >"\\fileserver1\Client_Deployment_Results\%Computername%.txt"

:END
EXIT

  • At the end of the script it will create two results files one in the local drive and one on the remote writable file, the environmental variable %COMPUTERNAME% is used to have text file created with the ‘machine_name.txt’ to keep the track.

Configuring the GPO

To get the individual machines to run this login script, GPO is used to help enforce the Startup script to machines to run at startup.

  • The startup script is the file that does the actual action. It could be almost any action, as noted above. Unlike the "old fashioned" method of using ADUC and the Profile tab of the users' account properties, the default location for GPO-initiated logon scripts is the deep within the SYSVOL special folder, which, by default, is shared on all Domain Controllers in an Active Directory forest, and is located in the following folder:

%SystemRoot%\SYSVOL\sysvol\<domain DNS name>\Policies\{GUID}\machine\Scripts\startup

  • Where %SystemRoot% is usually “C:\Windows”, <domain DNS name> is the DNS name of the domain, ‘dc.capitaland.com’, and {GUID} is a hexadecimal string representing the GUID (unique identifier) of the specific Group Policy Object in use. This folder, which is a part of the SYSVOL special folder, is replicated to all the Domain Controllers in the domain. Each GPO has its own internal User and Machine subfolders, and under them it has, if used, a Logon, Logoff, Startup and Shutdown subfolder where appropriate
  • Copy the logon script (CTRL+C) at the file level, during the creation of the GPO it will be necessary to paste the file into the UI.
  • Startup and Shutdown scripts run under the machine credentials. It is recommended that the “Domain Computers” group shall be given permission to any resources used by either of these scripts. For example, if the startup or shutdown script writes to a log file, the group “Domain computers” should be given read/write access to the file or the folder where the log file is located.
  • In order to assign the GPO and edit it, Group Policy Management console, or GPMC in short is used. This tool is not installed by default in Windows Server 2003, and neither is it installed by default in Windows Server 2008. In Windows Server 2008, GPMC is considered to be a "Feature", and you must install it before being able to use it. However, unlike in Windows Server 2003 where you must download and install the tool, in Windows Server 2008, GPMC is already a part of the operating system, you simply need to add it. If the Windows Server 2008 server is also a Domain Controller, GPMC will be automatically installed as part of the DCPROMO procedure. If it's not a DC, you'll need to manually add it.
  • Open Group Policy Management Console from the Administrative Tools folder (or gpmc.msc from RUN)

 

  • As described in the above paragraph, you decided to apply the script to ONLY a SPECIFIC SET of computers, expand the domain tree, locate the OU where the computers are located. Right-click the OU and select Create and Link a GPO Here

 Note: It might be possible that a GPO already exists and it is linked to the object level you need. In that case you don't need to create a new GPO; you can use the existing one

  •  In the New GPO window, give the new GPO a descriptive name, such as "Client Logon Script GPO". Click Ok

 

  • If you don't see it already, refresh the GPMC view and find the new GPO you've just created under the OU
  • When you click on the new GPO you might be prompted with a message window. Click Ok

 

  • Right-click the new GPO and select Edit

 

  • In the Group Policy Object Editor window, expand Computer Configuration > Windows Settings > Scripts

 

  • Double-click Startup in the right-hand pane
  • In the Startup Properties window, click Show Files

 

 

  • A window will open. The path will be a folder similar to the following: \\domain.com\SYSVOL\testdomain.com\Policies\{Guid}\machine\Scripts\startup. Paste the logon script you've copied in the previous part of this article. Close the window
  • Back in the Logon Properties window, click Add
  • In the Add a Script window, click Browse and you will see the logon script step #11. Whatever you do, DO NOT manually browse for the file, it should be in front of your eyes. If it's not there, check the previous steps for a mistake. Click Ok

  • Back in the Startup Properties window, see if the logon script is listed, and if it is, click Ok

 

 

  • Since we are targeting multi Architectural environment where we have windows xp, windows vista, and windows 7 machines, on windows vista and windows 7 machines “User Access Control” feature is enabled by default and any installation would require administrator to allow installation, to silently install the software we would need the feature to be disabled using GOP, follow the steps below

  

 

  • In Group Policy Management Editor expand Security Settings èLocal Policies èSecurity Options
  • In the right hand page scroll down and locate User Account Control:Behavior of the elevation prompt for Administrators in admin approval mode, double click on the option and click on check box Define this policy and from the drop down menu select Elevate without prompting and click OK

 

  • Next locate User Account Control:Run all Administrators in Admin Approval mode, double click on the option and click on Define this Policy and select the option Disable, click on OK
  • Close the Group Policy Object Editor window
  • Close the GPMC window

Replicating the GPO

To replicate the DCs in the domain by using either Active Directory Sites and Services, Replmon, Repadmin, or wait a few moments (depending on the number of DCs). As a simple follow up to this article, I suggest you use Active Directory Sites and Services.

Testing the Login Script

  • On one of the computers that is part of the domain, logoff the specific user account
  • Logon and test. If you don’t see the client software installed after about 15 minutes, go to command prompt

Note

On machines with Windows 7 as the Operating System, open as Administrator

 

  • Type following commands, this command will generate a report where you can see whether the policy is applied on the user or not, if you don’t see the policy applied type following command
    • C:\>GPresult /H: >C:\gpresult.html /Scope:Computer (windows 7)
    • C:\>Gpresult /Scope:Computer >C:\Gpresult.txt
    • To force the GPO update on the client machine apply the following command, logoff and login again to test
      • C:\>Gpupdate /force
  •  It is possible sometimes logon process completes but the script doesn't run properly, it can happen on clients running windows xp, or later running on fast network, the first thing to look at would be the event viewer at client machine and you can also look at the longon process logs Userenv.log file which is located in %systemroot%\debug\usermode directory, to enable debug loggin refer to article https://support.microsoft.com/kb/221833

Please post your comments and feedback on this post, shall you have any questions regarding this please post the questions in technet