Posts Tagged ‘Group Policy’

MS LifeCam Call Button and Office Communicator

Tuesday, November 24th, 2009

If you have one of the Microsoft webcams or headsets you’ll no doubt be aware that the the Call Button (by default) opens up Windows Live Messenger.  If you’re in a businesses that uses Office Communications Server however that’s probably not much use, you’ll actually want it to open up Office Communicator instead.

The other day I stumbled across this article on the MS site that provides an administrative template (adm) that will allow a company using Active Directory to configure the Call Button to trigger Office Communicator.  It’s a little thing I know, but it makes for a nicer user experience if you have MS hardware.

Anyways… essentially you need to save the following code into a .adm file, import this into a Group Policy and use that policy to configure your computers/users (more information on AD and Group Policy can be found here).  Obviously don’t mess around with AD or Group Policy unless you know what you are doing, and test everything before applying settings to end users!

CLASS MACHINE

CATEGORY !!MSHW

POLICY !!EnableMOCIntegration
KEYNAME "Software\Policies\Microsoft\Hardware"
EXPLAIN !!EnableMOCIntegrationExplain
VALUENAME "EnableMOCIntegration"
 VALUEON  NUMERIC 1
 VALUEOFF NUMERIC 0
END POLICY

END CATEGORY

[strings]
MSHW="Microsoft Hardware"
EnableMOCIntegration="EnableMOCIntegration"
EnableMOCIntegrationExplain="Enables MOC Integration"

; Online Help Strings
ADM_TITLE="Group Policy settings for Microsoft Hardware"
COMPUTER="Computer Configuration"
COMPUTER_EXPLAIN="Contains computer settings only."
SUPPORTEDON="Requirements:"

Windows 7 Device Installation without Administrator Privileges

Tuesday, November 10th, 2009

Supporting mobile workers is always a little tricky.  Whilst you need them to be able to work effectively, you don’t always want to grant them enough system access that they can break things whilst on the other side of the world where you can’t help them.

One of the big requirements for administrative access to systems is the ability to install new devices such as printers.  Windows has supported non-admin installation of drivers for years, but with the big caveat that the drivers are signed.  If they’re not then it won’t work, and often the manufactures don’t bother going through the time and expense.

Fortunately Windows 7 offers some help here by allowing you to point the system at Windows Update for driver installations.  When a device is plugged in Windows will check for appropriate drivers on the local disk (these can of course be pre-populated) and then if it can’t find any search Windows Update.

We’ve tested it with a few devices here, and whilst not everything is on Windows Update, it would seem that the majority of newer printers and devices are.  At the very least it’s a huge expansion of the drivers included out-the-box.

You can also search the Windows Update catalog so check whether certain devices are covered, and download those drivers manually.  I’ve not tried it, but I suspect that might also be useful should only Vista drivers be available.

image

Anyway, so how do you set this up?  Well there are two Group Policies that you need to set:

Computer Configuration > Policies > Administrative Templates > System > Device Installation >  Specify search order for device driver installation source locations = Enabled: Search Windows Update Last

This tells Windows to search locally for drivers, then search Windows Update for a compatible driver if none are found

Computer Configuration > Policies > Administrative Templates > System > Driver Installation > Turn off Windows Update device driver search prompt = Enabled

This removes the choice for an administrator to specify searching Windows Update and sets Windows to search Windows Update by default (given the search order specified above).  If this isn’t set the user is prompted to enter administrative credentials before searching Windows Update

Integrating Enterprise Search into Windows 7

Tuesday, October 20th, 2009

One of the things I like about Vista and Windows 7 is the way search has been integrated into almost every part of the interface.  Sure it’s not something you immediately start using, but for me at least it’s really grown into something that I use more than once a day to help find information and save me time.

On top of the ability to search the local disk, one of the great things about the Vista/2008/7/R2 windows family is the ability to federate search across a number of sources. 

What does that mean?  Search federation allows Windows to query against remote data stores without the need to index those locations itself.  Imagine that you wanted to search your SharePoint sites for a document, and you wanted to do it from within Windows.  One way to do this would be to get Windows to index all of the SharePoint content and keep its own index.   That’s not very efficient though, if there is more than one computer each one would need a copy, so in an enterprise that’s a whole lot of duplication. 

With federated search you enter your search query in one place, in this case Windows, and that query is then forwarded on to the other systems which have indexed content.  They then execute the query against their own index and send back the results.  Those results are then displayed back in the original application as if they were searched and indexed locally.  The benefit of this is that it’s much more efficient, each source can have it’s own index and search tool (provided it supports federation of searching) and only the query and results are passed over the network.

So, how do we make use of this?  Well Windows 7 supports search federation in the form of OpenSearch.  Fortunately quite a few different search engines support this, but for the sake of this post I’ll use SharePoint as I’m guessing that one of the more common data sources people will want to search. 

What it looks like
Before I get into how this can be setup and configured, here’s a screenshot of what it looks like in action:

SharePoint Search in Windows 7

This is a screenshot from Windows Explorer on a Win7 a test machine I was using today. First you can see that there’s an addition to the Favourites for your new search.  When you enter something into the search box, the results from the SharePoint location are returned directly into Explorer Window.  If you select one of the files and have the preview pane turned on you get a live preview of the document (the preview pane is something else I really find useful!).

In addition to the view above, you can pin your new search to the bottom of any other results… but more on that later.

So how do you set this up?  Well there’s the manual setup and an automated setup using Active Directory Group Policy.

The Manual Way
For manually setting up a new search location you can create a new OpenSearch Description file which you can then double click to install.  An OpenSearch Description file (.osdx) is an XML document that tells Windows where to send the search terms and how the results should be formatted.  These are fully document here, but I’ve included an example below:

   1: <?xml version="1.0" encoding="UTF-8"?>

   2: <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:ms-ose="http://schemas.microsoft.com/opensearchext/2009/">

   3: <ShortName>SharePoint Search</ShortName>

   4: <Description>Search SharePoint</Description>

   5: <Url type="application/rss+xml" template="http://yoursharepointsite.com/searchcentre/_layouts/srchrss.aspx?k={searchTerms}&amp;start={startIndex}&amp;cnt={count}"/>

   6: <Url type="text/html" template="http://yoursharepointsite.com/searchcentre/Pages/Results.aspx?k={searchTerms}&amp;page={startPage}&amp;cnt={count}"/>

   7: <ms-ose:ResultsProcessing format="application/rss+xml">

   8: <ms-ose:LinkIsFilePath>-1</ms-ose:LinkIsFilePath>

   9: </ms-ose:ResultsProcessing>

  10: </OpenSearchDescription>

When you double click on this .osdx file, Windows uses the information it contains to create two new files.  The first is a Search Connector (a .searchconnector-ms file) in the “%userprofile%/searches” directory, and the second is a shortcut to it in the “%userprofile%/links” directory.   It’s this shortcut that appears in the ‘Favorites’ folder in to Screenshot above.

The Automated Way

The simplest way to deploy the new search settings out to a number of computers is though Group Policy. 

As the search config is stored within the Search Connector, all you need to do is deploy the .searchcconnector-ms file and shortcut out to your target computers.  There are a few ways to do this, but personally I’d use Group Policy Preferences.  This will give you a good level of control over the targeting of the files, and easily allow you to adjust the settings over time.  You could also use things like logon scripts.

You can configure Group Policy Preferences to deploy files with the User Configuration > Preferences > Windows Settings > Files area of a GPO.  You’ll have to do this as a user based policy as the files must be copied into the User Profile, if you copied the files as a computer policy it would apply before a user was logged on so they would end up in the wrong place.

Within the Files Preferences, you have to specify a source file location and a target location.  For the source location I would tend to use the Netlogon share for your domain (//domain.com/netlogon/) as a copy will be on every domain controller and usually therefore local to the end users.  The target locations should be the same as those described in the manual steps above:

Search Connector: %userprofile%/searches/File.searchconnector-ms

Shortcut: %userprofile%/links/SearchTitle.lnk

As well as the source and target info, you also need to set a few of the other options.  The first is ‘Run in logged on user’s security context (user policy option)’ as this will ensure that the file is copied in context of the user logging on. 

You may also wish to consider whether to set the ‘Remove this item when it is no longer applied’ options so that the files are removed if you decide to remove the policy.

Adding Links to Your Search Connector

Following the steps above will add your new search location into the Favourites folder and allow you to search against it.  You can however also add your new Search Connector to both the ‘Search Again’ links that appear at the bottom of any search results, and to the Start Menu.  This is done by configuring the ‘Pin Libraries or Search Connectors to the ‘Search Connectors’ to the ‘Search Again’ links and the Start Menu’ Group Policy that can be found within the User Configuration > Policies > Administrative Templates > Windows Components > Windows Explorer area.

I hope this has been useful!

Filtering Group Policy to Windows 7 Computers

Friday, September 11th, 2009

During the development work we’ve been doing with Windows 7, one of the items we’ve been looking at is how we can filter the group policy applied to User Accounts by the operating system they are using.

The reason for this is that for a phased migration to Windows 7, you will probably need to account for people roaming between different computers – which may or may not have been migrated.  As the configuration applied to Windows 7 may be very different to that applied to older Windows XP computers we need a way of linking both sets of policy to the user accounts, but only applying the right one for the current OS.

If you have all of your user accounts in a single OU (or OU hierarchy) this is relatively straight forward.  The simple answer is to use Group Policy WMI filters.  These allow you to filter the application of Group Policy based on the results of WMI queries you make of the computer.  For example another good use of these is to detect whether a computer is a laptop or desktop, by querying the battery status you can easily set different configurations for things like Offline Folders on laptops.

After a bit of testing I found the following queries work for filtering policy to different OS levels, and computer roles:

Select * from Win32_OperatingSystem Where Version like “6.1%” and ProductType = “1”

To further filter policies based on versions and roles the following properties can be used:

Version
To filter the by OS version, change the Version property to:

Windows 7 or Server 2008 R2 = “6.1%”
Windows Vista or Server 2008 = “6.0%”
Windows XP = “5.2%”
Windows 2000 = “5.0%”

Product Type
To filter by the different roles the computer might have, change the ProductType property to:

Client = “1”
Server running a Domain Controller role = “2”
Member server (server that’s not a DC) = “3”

The % character in the above queries is a wildcard for any characters that follow, so you could therefore use Version Like “6%”to filter for OS’s which are Vista and later.

To apply the filters, you use the Group Policy Management Console (GPMC).  In the WMI Filters section in the right hand pane, click right-click and select New.  Then give a name and description, click Add then enter the filter into the Query box.  Then click Ok and Save

To apply the filter to a policy, select the policy in the right hand pane, then on the Scope tab under WMI Filtering select your filter.

There are a few limitations, like you can only apply one filter per Policy (but you can have more than one query per filter) and the Queries are a property of the policy not the link, but overall they’re a very powerful tool.

Vista Search Syntax

Wednesday, April 30th, 2008

In between some meetings today I did some reading around Windows Desktop Search and Vista Search.  Although its not something we currently ‘officially’ supply, we’re seeing more people using WDS and Google Desktop.  Not really a problem but when people start indexing the network shares our file servers and network don’t like it much…

So anyway I was reading up on how best to manage WDS, and it turns out its nice and simple as MS have provided an .adm file for Group Policy.  During my reading though I found this good article on the search syntax supported by WDS and Vista. 

The syntax is quite intuitive, and there are a surprising number of filters there, so you can do some pretty complex searches quite easily.

Here’s a few examples, but check out the full list here.

Property

Example

Function

author:name

author:patrick

Finds items with patrick in the author property.

from:name

 

from:patrick

Finds items with patrick in either fromName OR fromAddress, since "from" is a property name for both fromName and fromAddress.

Kind:type

kind:meetings

Finds meetings

Date

date

date:lastweek

Album

album

album:"greatest hits"

Group Policy Preferences

Friday, April 4th, 2008

Back in the day I used to look after big desktop deployments both here at Atkins and a few other places.  Managing large numbers of desktops is always a problem.  There’s no doubt that managed desktops are A Good Thing(TM), but the tools available to do the job were always a bit harsh on either the end users or the IT guys. 

Whilst Group Policy is great, you almost always needed other scripts and tools to get the complete result you wanted.  Whether those were included in the image or applied at logon it didn’t really matter, they were a pain to manage.  Group Policy also completely enforces the settings, there is no way to set the default value, but allow the users to edit the setting if they wished.  Once its set, that’s it for Joe User.

The new Group Policy Preferences functionality allows you to configure mapped drives, deploy files, setup shortcuts, quick launch buttons etc, manage ODBC sources, IE settings, all kinds of stuff.  It can also filter the settings on a per setting basis, no need to have new policies for each filter like GPO.  Plus the range of criteria available for those filters is huge.

There’s too much detail to go into here, but take a look at this screencast over at Technet Edge to see some examples.  It’s good stuff and will take a lot of work out of the more detailed config that enterprise managed desktops require.