Your can read about it and download it here: http://blog.insidelync.com/2011/02/microsoft-lync-powershell-cheat-sheet/.

In a nutshell it is a quick reference card for PowerShell use with Lync Server 2010.

1. The Lync Server Administration Tools Cannot be Installed Alongside the OCS 2007 or OCS 2007 R2 Tools.

If you try to install the Lync Administrative Tools on a machine that already as the OCS 2007 R2 Administrative Tools, you will see the following error:

Note: if you want to by-pass the Lync Deployment Wizard GUI to install the Administrative tools directly from the setup files, this worked for me:

• First install the core components from:  .. \Setup\amd64\Setup\ocscore.msi
• Next, install the administrative tools from: ..\Setup\amd64\Setup\admintools.msi.

2. You can View your OCS 2007 R2 Topology in the Lync Topology Builder

A key step in the the OCS migration process is to merge topology information. This merges data from a previous OCS 2007 or OCS 2007 R2 topology data into the Lync Central Management Store. See Microsoft TechNet Lync Server Migration (http://technet.microsoft.com/en-us/library/gg425746.aspx) for full migration details. This is a key step to allow side-by-side coexistence and user migration.

The “Merge 2007 or 2007 R2 Topology…” action from the Topology builder (http://technet.microsoft.com/en-us/library/gg398172.aspx) creates a root tree node named “BackCompatSite” which shows up in the Lync Topology Builder where you can view your OCS Topology components.  The OCS information under this node is just read-only; no actions can be taken.

Important Notes:

• Always save a copy of your existing Lync topology first.
• Before you merge the topology, you need to install the “WMI Backward Compatibility Package”.  This compatibility package is located in the Lync distribution at:
  • …\Setup\amd64\Setup\OCSWMIBC.msi
• The “BackCompatSite” OCS tree node is a snapshot of your legacy OCS environment – it does not keep it synchronized! If you makes changes, you will need to remerge.

The WMI classes that are installed with the OCS Administrative Tools and Server Roles are part of the Office Communications Server Management API.  Below I provide a handy reference to the most useful MSDN OCS WMI information.  Note:  R2 = OCS 2007 R2; R1 = OCS 2007.

* Note: Practically speaking, the class scope affects your ability to use the class in two ways:

1. The WMI class might only be available on a particular machine (server role), meaning your script will need to remotely connect to that machine to get access to it. If there is a “*” in the Admin column, you need to connect remotely to the machine.
2. You need the appropriate access rights to a particular scope if it is a Singleton.  For example, if your script is running in a child domain, and a particular class is can only have one instance in the Global scope (AD), the user running your script needs permissions to access to the parent AD domain.

(Note: you’ll want to click on the “Vote here” hyperlink which can be a bit lost in all the other text)

In a nutshell there are 4 options:

1. Use a Windows Script (e.g. VBScript or JavaScript/JScript)
2. Use the OCS 2007 Resource Kit Script (LCSEnableConfigureUsers.wsf)
3. Use Microsoft Powershell
4. Use a Bulk Active Directory Import/Export Tool

I explore these 4 options below. The first 3 options make use of WMI under the covers to set the “Enabled” property on the OCS user in Active Directory.

Important notes for the first 3 (WMI-based) Options:

Option 1: Using a Script (e.g. VBScript or JavaScript/JScript)

I’ve put together a sample VBScript to enable or disable a single OCS user.  Set the g_userURI and g_OCSEnableUser variables accordingly. You can use the guts of this script to easily do it for a batch of users (i.e. read a list of users from a file).

Option 2: Using an OCS 2007 Resource Kit Script

The script requires 2 input files: one file containing a list of users to enable or disable (specified with their SIP or distinguished names), and another file with the corresponding OCS user settings.

These files require some time and effort to set up, so this option is best for big batch operations. The Resource Kit ReadMe contains good information on prerequisities and permissions expected for this script.

Option 3: Using Microsoft PowerShell

Microsoft PowerShell is a powershell scripting environment that comes with a WMI provider that can be used to manage OCS. Powershell can be downloaded here.  Starting in Windows 2008, Powershell was included with part of the operating system. You can download Powershell 1.0 here: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx if you have Windows 2003. Once installed, you can easily script a solution to enable/disable OCS users.

Option 1:  The underlying AD user object has been enabled for OCS (or LCS) at least once.

If the AD user has never been enabled for OCS (or LCS), you will not be able to use this method to enable the user (they won’t show up in the MSFT_SIPESUSERSETTING class).  See Option 2 (below) .

To get a list of OCS Enabled users, you can simply issue the command:
    > get-wmiobject -class msft_sipesusersetting | ForEach-Object { $_.Enabled = true}

To enable a particular SIP user for OCS:
    >   get-wmiobject -class MSFT_SIPESUserSetting | where-object { $_.PrimaryURI -eq “sip:userid@SIPDomain” } | % { $_.Enabled = $True; $_.put() | out-null }

• One or more of your parameters is not correct, or,
• The OCS WMI object already exists for that user

Option 4: Use a Bulk Active Directory Import/Export Tool

Many OCS user features that can be set in the OCS management console GUI can be set or changed through underlying Active Directory (AD) attributes.  If you are attempting a bulk change, you’ll generally want to export the users, modify the data (to turn a feature on or off), and re-import the data.  The following two command line tools will allow you to do this:

1. LDIFDE – Export / Import data from Active Directory.  LDIFDE  Import/export information from/to Active Directory. It queries any available domain controller to retrieve/update AD information.
2. CSVDE (Comma Separated Value Data Exchange).  CSVDE is a small command-line tool that can import and export data from AD in a CSV file. It is included in Windows 2003 installs by default (usually in the %windir%/system32 directory).

Although not a command-line tool per se, ADModify.NET is an excellent GUI based tool for making batch changes to objects in AD.  It can record all changes that it made to an XML file which is handy.

In a nutshell it exposes many of the available OCS Powershell cmdlet’s (actually a wrapper around the WMI provider) in an easy to use nice GUI that covers everything from OCS User Settings, Enterprise Voice, and Forest, Pool, and Server settings.

You can read about and download the OCS 2007 Powerpack here: http://www.powergui.org/entry!default.jspa?categoryID=21&externalID=1926&fromSearchPage=true.

MVP Dmitry Sotnikov has an excellent overview of the OCS pack on his blog at: http://dmitrysotnikov.wordpress.com/2008/06/20/ocs-management-console-on-steroids/