Archive

Archive for September, 2012

Review: Lync BusyLight by Kuando

September 24, 2012 Leave a comment

I’m sure you’ve had this happen. You’re sitting at your desk, deep in thought on a serious issue, and someone walks into your area and just starts talking. You don’t want to be rude and ignore them, and you really need to restrain from your desire to strangle them for causing that great troubleshooting thought to leave you head. If only they could see your Lync presence and know that you’re in Do Not Disturb. Well, now they can!

Lync BusyLight Introducing the BusyLight for Microsoft Lync from Kuando. This slick little device has a multicolored light on the top, and indicates your Lync presence using one of four colors. It does this via a USB connection and a simple little application that runs in the system tray. Available? The unit glows green. Do Not Disturb? Deep red should keep people away. And, of course, the normal green for available and yellow for away.

Also built into the unit is a call alert feature that blinks blue to indicate an incoming Lync call, and a small speaker with customizable ring tones.

The unit is adjustable for angle and can be attached to a wall or cabinet with the included velcro fastener.

I’ve had mine for several months now, and everyone in my house knows that while my home office door may be open, all hail the BusyLight before interrupting. I’ve taken it to client sites, too. In my current cube farm, my cube is a considerable distance from my team mates. So I placed it on top of my cube partition, and they can see it before making their way towards my cube.

The unit works great, but there is a little issue that it causes. The “what’s that?” issue. People who come up to my cube, point at it, and wonder what it does. So I take my time to explain what it is and what’s it purpose is. I even made a little sign with a little blurb about the device, complete with color coded indicators.

BusyLight

BusyLight

This is a neat little unit that has really helped me stay focused and uninterrupted. The only problem I’ve had with the unit is that over distance, the colors can be a bit washed out. The red for busy and the deep red for Do Not Disturb are a little too close together. And the “available” green fades a little towards the yellow of “away”. The only other suggestion I’d make is that the USB cord be a little longer. But that’s just my personal preference.

The BusyLight works with Windows XP SP3, Vista, and 7. A Windows 8 driver will be available soon. It is available from many resellers for about $49.00 USD.

Categories: Lync Server Tags: ,

Function: New-SignedScript – Easily Sign One or Many Scripts with Your Code Signing Cert

September 20, 2012 Leave a comment

Signs a PowerShell script with a code signing certificate.

Syntax

New-SignedScript [[-path] ] [-Verbose] [-Debug] [-ErrorAction ] [-WarningAction ] [-ErrorVariable ] [-WarningVariable ] [-OutVariable ] [-OutBuffer ] [-WhatIf] [-Confirm]

Detailed Description

One of the concerns about using a PowerShell script is that it often requires the user to change the Execution Policy on the machine the script is running on. This can cause security concerns, because when the Execution Policy is lowered, any script can run, including those with malicious intent. For more information on setting the Execution Policy, see Set-ExecutionPolicy.

Of course, you need a code signing certificate in order to sign scripts. Fellow Exchange MVP Mike Pfeiffer wrote an informative article, Obtaining a Code Signing Certificate and Signing PowerShell Scripts that covers using an internal Certificate Authority. Third party Certificate Authorities (CAs) such as Digicert also provide code signing certificates. I can’t recommend Digicert enough. I have both a standard code signing certificate and an Extended Validation code signing certificate.

But signing scripts manually can be a little cumbersome. This function gets the current code signing certificate, verifies it’s not expired, and then signs the script. The script will only sign .ps1 files, and will not attempt to sign a script that’s already signed.

Example

New-SignedScript -path [path to script]

such as

New-SignedScript -path .\myscript.ps1

You can also pipeline files to this function, for example:

Get-Item *.ps1 | New-SignedScript

Installation

Nothing special here. Once you have a valid code signing certificate installed, the function should work as designed.

Download

v1.1 – 06-10-2014 – New-SignedScript.v1.1.zip

v1.0 – 09-20-2012 – New-SignedScript.v1.0.zip

Changelog

See changelog for info on latest versions, including bug fixes, code tweaks, etc.

Categories: PowerShell Tags: , ,

Review: Jabra UC 250 MS Headset – Great Lync Travelling Headset

September 17, 2012 Leave a comment

Do you do a lot of travel and need to stay connected via Lync or Skype? The Jabra UC 250 MS headset is a nice addition to the travelling arsenal. The “MS” designation is for Microsoft Lync. It’s a simple mono over-the-ear design with an unobtrusive microphone and USB cable. The cable includes one of the better control units I’ve seen. Many control units have a basic mute switch that just cuts the audio to the computer. The UC 250 MS control unit has a button that mutes the Lync client. So, not only can you unmute from the control unit, but you can unmute from the client as well. Very nice, as I’m sure most people who use the typical mute option on a headset find themselves scrambling to unmute in a hurry. The mute button has a nice bright red LED to indicate the headset is muted. It also has your typical volume controls, and  a handy on/off hook button. The device is supported by the Jabra  PC Suite software. The UC 250 MS comes with a taco shaped zippered case for storage. It’s available online in the $40 range.

Jabra UC Voice 250 headset

Jabra UC Voice 250 headset

DSP Digital Signal Processing yields great sound in applications such as Lync or Skype. Recipients have reported that my voice was clear and accurate, and didn’t have that typical cheap headset sound. The cord is long enough for my use, but was a bit stiff for me. I didn’t need to use the PC Suite software, so I can’t comment on it here. One thing I did notice is it was a tad cumbersome to get it on my ear. But once it was on, it stayed in place, and the gel style insert was comfortable even for longer calls. My laptop quickly found the headset and had the drivers installed without issue. A simple selection change in Lync and I was off and running.

I’ve used the headset for many calls and can say it’s a great headset for its price point. Simple, inexpensive, and it works. It doesn’t hurt that it takes up hardly any room for storage. If you’re looking for something to toss in your backpack or use at your desk, check out the Jabra UC 250 Voice MS.

Categories: Lync Server Tags: ,

Changelog: New-ExpiringCertificatesReminder.ps1

September 14, 2012 Leave a comment

This is the changelog page for New-ExpiringCertificatesReminder.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v1.2 – 01-27-2014

  1. -noprofile switch added to install routine
  2. minor code tweaks per best practices

v1.0 – 09-11-2012

  1. Initial version
Categories: PowerShell Tags: , ,

Script: New-ExpiringCertificatesReminder.ps1 – Receive a Reminder When Certificates Have Expired/Are Expiring

September 14, 2012 Leave a comment

Detailed Description

Sometimes we’re so deep in projects or putting out fires that some things just get forgotten, or we don’t get that far down the “to-do” list. Some of those things aren’t that big of a deal and don’t impact users. Other tasks can have drastic impact. Such as forgetting to renew your server certificates. It’s true that some services like the phenomenal Digicert will remind-you-to-death about certs that are expiring. But not all services do that, or they do it once and are forgotten. Other certs, like internal certs, don’t generate a reminder – and some environments don’t allow, or aren’t configured to automatically renew internal certificates. So this lazy, forgetful guy decided to do something about that. A script was born.

This script monitors certificates in the Local Machine store on the local server, and sends a reminder when a cert is expiring soon, or has already expired. An example is shown below.

Sample email about an expired certificate

Sample email about an expired certificate

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Download the script and ImageFiles.zip files from the DOWNLOAD section below. Copy the image files to a location available to all users who will receive the reminder email. I suggest a web server with public access. NOTE: These images are the SAME files and names as the ones for New-PasswordReminder.ps1, so you can use the same path if you use both scripts.

Open the script in a text editor and edit the variables in the param block to suit your needs. At a bare minimum, you need to adjust:

  • $Company – this should be your company name
  • $PSEmailServer – this is the email server the script will send the emails to
  • $EmailFrom – this is the SMTP address that the emails will come FROM
  • $EmailTo – set this to the SMTP address of the user/distribution group that should receive the reminder emails
  • $HelpDeskPhone – if not empty, this appears in the email message
  • $HelpDeskURL – if not empty, should be a URL to a web version of the email. If blank, the “If this email does not appear…” and “This email was sent by…” lines shown in the above example are not included.
  • $ImagePath – where the images are stored. This should be publicly reachable for users checking email from mobile devices and web clients

optionally, adjust $threshold from the default 15 to indicate how many days in advance the script should start reminding about an expiring certificate.

Save the script.

If you don’t already have a Receive Connector in Exchange to allow PowerShell scripts to send email, create one using the information at Creating A Receive Connector To Use For Sending Email From PowerShell.

If you have certs that are already expired, or are expiring soon, you can manually run the script to test. To do that, open PowerShell and type

New-ExpiringCertificatesReminder.ps1

Once everything is done, you can run the script in Install mode:

New-ExpiringCertificatesReminder.ps1 -Install

and the script will prompt for the user password, then automatically create a scheduled task on the local server to run every day at 7:30am. You can open the Scheduled Tasks GUI and adjust parameters as needed, but I’ve found the defaults to be fine.

Repeat on any other servers you’d like to monitor.

Download

v1.2 – 01-27-2014 – New-ExpiringCertificatesReminder.v1.2.zip

v1.0 – 09-14-2012 – New-ExpiringCertificatesReminder.v1.0.zip

ScriptImages.zip – these are the images specified in the emails

Changelog

See the changelog for information on what’s changed/included in each version.

Categories: PowerShell Tags: ,

Function: New-FirewallRule – Add Windows Firewall Rules Via PowerShell

September 14, 2012 Leave a comment

Some of my scripts, namely Get-CsConnections.ps1, require specific firewall rules be created in order to operate correctly. So I set out to automate as much as possible the creation of these rules. A function was born.

This little function can do pretty much everything the Windows Firewall wizard can do. You can specify local and remote ports, local and remote IP addresses, programs, services, direction Inbound or Outbound), TCP/UDP or Any, and more. I borrowed some of the info from the Windows Firewall chm file for the comment-based help file in the function. Just run

Get-Help New-FirewallRule

for detailed help.

I tried to think of (and test) common requirements for firewall rules, but if I’ve left something out, or something isn’t working as expected, feel free to leave a comment below.

Syntax

New-FirewallRule [[-name] ] [[-localPorts] ] [[-remotePorts] ] [[-localAddresses] ]
 [[-remoteAddresses] ] [[-program] ] [[-serviceName] ] [[-description] ] [-outbound] 
[-udp] [-block] [-readonly] [-any] [-domain] [-public] [-private] [-WhatIf] [-Confirm] []

Name  This is the name of the firewall rule. As a best practice, give the firewall rule a unique name. If two rules have the same name, then you cannot easily manage them by using the netsh or PowerShell commands. Do not use the name “all” for a firewall rule because that is the name of a Netsh command-line tool keyword.

LocalPorts  If you are using the TCP or UDP protocol type, you can specify the local port by using one of the choices from the drop-down list or by specifying a port or a list of ports. The local port is the port on the computer on which the firewall profile is applied.

RemotePorts  If you are using the TCP or UDP protocol type, you can specify the local port and remote port by using one of the choices from the drop-down list or by specifying a port or a list of ports. The remote port is the port on the computer that is attempting to communicate with the computer on which the firewall profile is applied.

LocalAddresses  The local IP address is used by the local computer to determine if the rule applies. The rule applies only to network traffic that goes through a network adapter that is configured to use one of the specified local IP addresses.

RemoteAddresses  Specify the remote IP addresses to which the rule applies. Network traffic matches the rule if the destination IP address is one of the addresses in the list.

Program  Use this option to match network packets going to or from a specified program. If the program is not running, then no packets match the rule. Type the complete path to the program. You can include environment variables, where appropriate. When you add a program to the rule, Windows Firewall with Advanced Security dynamically opens (unblocks) and closes (blocks) the ports required by the program. When the program is running and listening for incoming traffic, Windows Firewall with Advanced Security opens the required ports; when the program is not running or is not listening for incoming traffic, Windows Firewall with Advanced Security closes the ports. Because of this dynamic behavior, adding programs to a rule is the recommended method for allowing unsolicited incoming traffic through Windows Firewall.

ServiceName  Use this option to apply the rule only to services, not to other processes. Specify the short name of the service to which you want the rule to be applied.

Description  This is a description of the rule. Use this to provide information about the rule, such as the rule owner, the rule requester, the purpose of the rule, a version number, or the date of creation.

Outbound  Configures the rule as outbound. If not specified, the rule is created as inbound.

UDP  Use this option to specify that the rule should filter UDP traffic. If not specified, and -Any is also not specified, the rule will filter TCP traffic. Cannot be used with -ANY.

Block  Use this option to explicitly block any network packet that matches the firewall rule criteria. The block action takes precedence over the allow action, unless the Override block rules option is selected when the firewall rule is created.

ReadOnly  If used, the rule will be created and attributes such as Program, Protocols, and Ports cannot be edited after creation. To change these settings, delete the rule and recreate it.

Any  Use the option to filter traffic from any protocol. Cannot be used with -UDP.

Domain  Applies when a computer is connected to a network that contains an Active Directory domain controller in which the computer’s domain account resides.

Private  Applies when a computer is connected to a network in which the computer’s domain account does not reside, such as a home network. The private profile settings should be more restrictive than the domain profile settings. A network is assigned the private type by a local administrator.

Public  Applies when a computer is connected to a domain through a public network, such as one available in airports and coffee shops. The public profile settings should be the most restrictive because the computer is connected to a public network where the security cannot be as tightly controlled as it is in an IT environment. By default, newly discovered networks are assigned the public type.

Examples

There is a vast number of combinations that can be used to create rules. I’ve tested a bunch, but cannot possibly test every conceivable combination. Here are a couple of examples:

New-FirewallRule -Name "Test Rule" -Description "My cool Lync rule" -Domain -Public -Private -Any -Program "C:\Program Files\Microsoft Lync Server 2010\File Transfer Agent\FileTransferAgent.exe" -ReadOnly
New-FirewallRule -name "World Wide Web Services" -description "An inbound rule to allow HTTPS traffic for Internet Information Services (IIS) [TCP 443]" -domain -private -public -localports "443" -Program "System"

Installation

No installation needed. But the function does need to run in an elevated session.

Download

v1.0 (09-14-2012) New-FirewallRule.v1.0.zip

Changelog

See the changelog for information on features and bugs fixed in various versions.

Categories: PowerShell Tags:

Changelog: New-FirewallRule

September 14, 2012 Leave a comment

This is the changelog page for New-FirewallRule. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v1.0 – 09-14-2012

  1. Initial version
Categories: PowerShell Tags: ,

Script: Grant-CsPolicyByADGroup.ps1 – Assign Lync Policies to Users According to AD Group

September 10, 2012 11 comments

Lync 2013 logo 128x128This idea is from a LinkedIn post that I responded to. The original poster wanted to know if there was a way to manage Lync external access policies based on AD group membership. Absolutely!

This is a fairly simple script that uses a scheduled task that runs every 4 hours, looks at the members of a given AD security group, including nested groups, and applies a Lync policy to each member. The name of the AD security group and the type and name of the policy are all configurable. The ActiveDirectory and Lync PowerShell modules are used to complete this. The actual moving parts are pretty simple – really just two lines of code. But some extra error catching, installation code, and safeguards make it a tad bigger.

Caveat – users get policies when they launch the Lync client. So even though a policy might be assigned to a user, they won’t see any change until the client is restarted.

Caveat #2 – if you configure this script with several scheduled tasks to handle different policies and different AD groups, make sure users don’t end up in multiple groups, or you could have unintended results. Also removing a user from a group does NOT revert their policy back. The reason I didn’t add that is because moving a user from one group to another could cause problems if the script set them back to a default policy, yet another group needed to change it to a different policy.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Download the script from the DOWNLOAD section below. Open it in your favorite text editor.

Find the line that reads

[string]$GroupDN = "",

and put the Distinguished Name of the group in between the quotes. For example

[string]$GroupDN = "CN=Lync Policy Group,DC=contoso,DC=com",

Next, define the policy that will be granted to members of the group. Find the line that reads

[string]$PolicyName = "",

and put the name of the Lync policy in between those quotes, such as

[string]$PolicyName = "Executives External Access Policy",

The last thing we need to do in the script file is define what KIND of policy we’re going to grant.

Find the line that reads

[string]$PolicyType = "ExternalAccess",

And adjust accordingly. The allowed values are Archiving,Client,ClientVersion,Conferencing,ExternalAccess,HostedVoicemail,Location,Mobility,Pin,Presence,Voice to represent the various types of policies you can apply to a user. The default is ExtnerAccess.

Next, ensure that the server where the script will run has both the ActiveDirectory and Lync PowerShell modules installed. Domain controllers typically have the ActiveDirectory module, and Lync servers have the Lync module. Install the appropriate ones using these steps.

To install the ActiveDirectory module, open PowerShell and type the following:

Import-Module ServerManager
Add-WindowsFeature -name AD-Domain-Services –IncludeManagementTools

To install the Lync Server Management Tools, which includes the PowerShell module, install the core components. See Install Lync Server Administrative Tools for details.

This will ensure that both modules are available. The ActiveDirectory module is used to get the members of the AD security group, and the Lync module is used to actually grant the policy.

The script must run as a member of the CsUserAdministrator or CsAdministrator groups, as those have the rights to assign policies.

Next, open PowerShell and run the script with the -install switch. The script will prompt for the password of the currently logged on user, and then create the scheduled task to run the script every 4 hours.

Grant-CsPolicyByADGroup.ps1 -install

The scheduled task will run every 4 hours, with a start time of when you ran the -install option. You can open the scheduled task in Task Manager and adjust as needed.

You can run the script manually as well. Just run

Grant-CsPolicyByADGroup.ps1

Note that it may take a while before the policy is visible on the user account due to AD replication.

Download

v1.5 – 02-08-2014 – Grant-CsPolicyByADGroup.v1.5.zip

v1.4 – 01-27-2014 – Grant-CsPolicyByADGroup.v1.4.zip

v1.2 – 10-16-2012 – Grant-CsPolicyByADGroup.v1.2.zip

v1.1 – 09-19-2012 – Grant-CsPolicyByADGroup.v1.1.zip

v1.0 – 09-10-2012 – Grant-CsPolicyByADGroup.v1.0.zip

Changelog

See the changelog for this script for a description of changes with each release.

 

Changelog: Grant-CsPolicyByADGroup.ps1

September 10, 2012 1 comment

This is the changelog page for Grant-CsPolicyByADGroup.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v1.5 – 02-08-2014

  1. swapped in new Set-ModuleStatus function
  2. cleanup of param block per best practices
  3. cleanup of functions per best practices
  4. replaced aliases with correct full cmdlet name per best practice

v1.4 – 01-27-2014

  1. Fixed PowerShell v2.0 compatibility
  2. minor code cleanup
  3. -noprofile switch added to install routine

v1.2 – 10-16-2012

  1. Better handling of nested user groups and members

v1.1 – 09-19-2012

  1. Added support for nested AD groups
  2. Added variable in param() block to define type of policy to apply to users
  3. Optimization of Set-ModuleStatus, Install, and Remove-ScriptVariables functions

v1.0 – 09-10-2012

  1. Original version
Categories: Lync Server Tags:

Lync Content at Microsoft Exchange Conference (MEC)

September 7, 2012 Leave a comment

Microsoft has finally released some of the details of what kind of content is available during Thursday, September 27th – the day after MEC ends. A 6 and a half hour post-day training session is being given by Lync MVPs Mike Stacy, Tommy Clarke, and Derek Kerr. The session, The New Lync Server 2013, covers three main areas of the new version. Web App Server (formerly known as WAC), video, and architectural improvements. Additional information new features and migration and coexistence with legacy versions will also be provided.

Those interested in attending should check out the information at http://www.mecisback.com/enhancedLearning.aspx. Cost for the session is $400.