Posts Tagged ‘Active Directory’

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:"

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.

Idle thoughts about Azure and the Cloud

Wednesday, July 15th, 2009

Yesterday whilst I was checking my mail I noticed this tweet from Steve Clayton at MS:

image

As I’d had a few conversations about Azure earlier in the day it got me thinking.  At the time I replied back saying that maybe there’s some confusion out there about where Azure would fit within a company’s overall infrastructure.  Hopefully most large companies will be on the ball and understand how cloud services can be used, but smaller organisations that might have less mature IT capabilities may not yet understand where they fit or how best to use them.

Whilst I was sitting in traffic earlier today I started to think about ways that platforms like Azure or Amazons EC2 might be useful to me, either personally or at work (can you tell I’m a geek?).  To be honest there are loads, but a really basic example might be something like this (it may be stating the obvious!)…

If other organisations are anything like the ones I’ve worked in they’ll use – and rely on – dozens of internally developed applications.  These might be as trivial as custom room booking tools to more critical ticketing systems or internal shopping carts for services. 

Traditionally these web or client-server apps would end up needing their own servers in a rack somewhere, burning power and depreciating nicely.  This is ok in the short/medium term, and you might use some virtualisation to get better utilisation out of the hardware.  Even so, the chances are you’ll still be paying for things like software maintenance and you’ll still need to support those systems as well as the app itself.  What’s more, as these apps and their servers age, the level of support they need will probably increase but at the same time the willingness of the business to pay for upgrades or updates will probably decrease.  After all its worked fine for years why should they pay more now?  This is where cloud services can help…

What if rather than hosting your shiny new application a server that you buy, rack and support yourself, instead you upload your application to (for example) the Azure Services Platform.  It supports many of the common platforms like .net, PHP etc. so there shouldn’t be too many changes to the underlying code (I’ll caveat that by saying I’ve not done it myself, so I’m basing this on the conversations I’ve had with MS and those that have).  In effect you have the same application running out in the cloud rather than on your own kit.

There is of course more to consider, basic things like cost through to more in depth subjects like authentication and security.

In terms of cost parity it largely depends on how utilised the servers are.  Cloud services like Azure and EC2 tend to be billed based on usage, i.e. so many cents per hour of CPU time, and so many cents per GB of storage used.  It’s hard to generalise whether this is cheaper or more expensive than owning your own kit, but you have to remember that those cents per hour of CPU include all the running costs – hardware, OS, power, cooling, hardware support, software support, ongoing patching, upgrades overtime etc.  I can say that where I’ve looked at this sort of thing in the past cost have looked pretty good in comparison.  Especially when you consider that the initial setup cost is far lower (no need to buy kit) and you don’t need to worry about old servers going out of support and having to chase your business/customers for funds to upgrade them in five years time.

Having an app out in the cloud is all well and good, but how do people sign into it?  Is it another username and password for people to remember?  In some cases the answer is probably yes, but where I think MS have a huge advantage is their work to improve the authentication experience for apps hosted on Azure – particularly for business customers. 

Their federation tool, currently called Geneva, that allows you federate Active Directory with Azure (I’ve written about this before here).  In effect, if you have Geneva setup then accessing an application hosted on Azure would have the same user experience as if it was hosted on your own network and domain.  Their usual username and password will authenticate them, and in most cases will sign them in transparently using integrated authentication.

The security of cloud services is always a question that comes up, and as this weeks news about leaks from Twitter have proved is something you have to consider very hard.  Whether it’s more or less risky than publishing an application to the internet yourself is up for debate.  Nonetheless it’s a question that you’ll probably have to answer when asked.

Anyway, that’s a pretty basic example, but it’s probably a scenario that’s fairly common.  Where private clouds might fit within this is another matter altogether!

Best Practice Active Directory Schema Updates

Monday, May 18th, 2009

It’s been a while since I had much to do with the techie side of looking after an AD, but a few bits of work we have on at the moment have had me thinking about AD and Schema updates in particular. 

It was quite a coincidence then that Jane Lewis over at MS posted up some good info on MSIT’s process for evaluating and implementing extensions to MS’s own AD Schema.

Whilst I’ve pasted some of the process below, its well worth heading over to Janes blog as she has some really good info over there.

I’ve added a few bit and pieces to the the high level process she describes below:

  1. Validate the justification for the Update – it is after all a one time procedure affecting the entire Forest.
  2. Fully define the type of change (Update, Modification, Depreciation)
  3. If the proposed change is a customized update from a third party, make sure that they provide a valid set of .LDIF files to analyze and that they have complete documentation
  4. Check whether base schema already has attributes or objects in it.  They may be affected by a change.
  5. Evaluate the risk of making the change
  6. Make sure that a Schema update is this the only way to effect your change
  7. Make sure you have a complete explanation of the update written and approved
  8. Define the list of roles and responsibilities for the Schema Update and make sure everyone knows what they are needed to do
  9. Stage the implementation of any Schema Change, test any change out in a non-production forest and thoroughly test it before implementing in a production environment.

Jane also provides a link to some docs and webcasts at MS that might be useful if you’re thinking about schema changes to your AD.

‘Geneva’ Identity in the Cloud

Tuesday, November 4th, 2008

One of the more interesting things to come out of the recent PDC conference (for me at least) was the work MS has been doing around identity in the cloud.  It’s always looked like a bit of a stumbling block for the adoption of cloud services, especially for enterprises where simple user interfaces and single sign-on have been a focus for years.

The main points that I picked up on were:

Identity

The Microsoft Federation Gateway – provides an identity and federation gateway into MS provided/hosted services including Azure and Live ID.

The Microsoft Services Connectorallows you to federate your Active Directory with MS to gain access to services hosted in their cloud. 

‘Geneva’ Servera standards based Security Token Service that allows federation between your AD and any other claims based service (including the MS hosted services)

Live ID and Open ID – Live will become an Open ID provider allowing the 400 million Live ID’s to use Open ID sites and visa versa.

Those are massive simplifications of course. 

Brought together these services and solutions could make life much easier for a lot of people.

– As an Enterprise we would be able to provide services from an Azure platform without any worry about authentication or identity.  Whether that be hosted Exchange, SharePoint, or just some internally developed apps the existing AD and it’s accounts can be used.

– ISV’s can provide solutions knowing that they’ll never have to worry about managing accounts and passwords for people.   No need to worry about password resets – the customer will deal with that for you.  Selling a license to a company?  No need to worry about employees leaving and still having access – the customer will remove their accounts anyway (well it depends who they are selling to I guess, but you get the idea). 

– As an end user my work username and password will get me seamless access to my work systems, and my personal ID (whether LiveID or OpenID) will work on more sites, so less accounts and passwords to remember.

I’ve just been watching this session on the ‘Identity Roadmap for Software + Services‘ over on the PDC site.  It gives are really good overview of what’s being planned and demo’s some scenarios where these new services might help.  It’s well worth a look.

Apple Mac’s in Active Directory

Wednesday, July 16th, 2008

I just found this pretty good video on the apple site describing – at a high level – Mac integration with Active Directory. 

http://seminars.apple.com/seminarsonline/activedir/apple/

For someone from a Windows background (like me) it’s worth a look.  It’s also interesting to see the difference in style between the Apple and MS.  Given the brand personas of the two companies you’d expect the styles to be reversed, with the more friendly informal stuff coming from Cupertino rather than Redmond.  But, you can’t fault the content.

Things I need to think about…

Thursday, May 8th, 2008

Apologies for this post, I’m writing it to collect together my own thoughts so it’ll probably be even more disjointed than usual!

So… we’re more or less a Microsoft shop here.  We run a standardised Windows XP desktop supported by Active Directory, Systems Management Server (SMS) and a host of Windows based application services.  This is all managed by a pretty skilled operations team and support by a decent service desk and desktop support organisation.  In summary pretty much all the technology and skill is Windows/PC focused.

We’re now seeing an increasing demand for Mac desktops and laptops, especially from the design community.   I need to work out what the impact of adopting a multi-platform desktop fleet will be both technically and from a service management perspective.

I no particular order I reckon I’ll need to consider the following to some degree or another.  It’s probably worth noting here that some of this may have obvious solutions, but I’ve no really experience of Macs – looking forward to learning though!

Software Delivery
Any computer is pretty much useless unless you have applications to run on it, so this is a fairly important point.  At the moment we have fairly robust software delivery and asset management.  End users request an application through a web ‘shop’ and the software gets delivered through SMS onto their computer. 

How will this work with Mac’s?  We don’t really want to go back to a word where we’re handing out CD’s – the asset management of that is too hard.  So from a technology perspective we’ll need some way delivering the applications. 

That will include amendments to our shop front so that people can select between PC and Mac versions of Applications, and also the actual delivery solution.  Given that for now the Mac user base is likely to be much smaller than the PC base, it would seem to make sense to try and use SMS rather than adopt a new system – we already know and use SMS.  it looks like there are a few solutions out there to achieve this.

Applying Policy
There are certain company policies and configuration that we have to apply to our corporate desktops – proxy server settings for example.  Within the Windows world we use AD Group Policy to achieve this.  How do I go about doing this with Mac’s?  Again, there appear to be tools out there which help.

Patching
This is where my ignorance of Mac’s starts to show… :)  Now I understand that Apple runs a Software Update service, and that from the client you can select which updates to install, which to hide etc.  What I’m not sure about at the moment is whether there is a WSUS equivalent that will allow an organisation to administratively select and schedule updates from a central point.   It’s possible the software delivery solution will deal with this, but for now I’m not sure.

Desktop Support
Speaking to friends at other companies that support Mac’s it would seem that although Mac’s require less overall support than a PC, the hardware does tend to fail more regularly.  Whether this is true I’ll wait and see (flame suite on none the less…). 

In either case there’s a skills gap here as we don’t currently have any Mac support skills in-house.  Potentially this might mean we could bring someone in to help, at least in the short-medium term to get us over the initial learning curve.  It’s something we would need to address fairly early on in order to provide a decent level of service.

With hardware support the likes of HP and Lenovo have hoards of guys just waiting to warranty repair faulty kit.  The impression I get so far is that the same isn’t likely to be true with Apple.  Potentially that means we’ll have to have Mac’s in stock and on-site to replace faulty units quickly whilst repairs are organised out of band.

SharePoint Compatibility
We use SharePoint to deliver our intranet and provide the usual team and project workspaces, so compatibility with this and the workflow and applications built on it is pretty important.  This will probably drive which browsers we provide, but may also have lower level implications.

Exchange Compatibility
As with the SharePoint item above, corporate email is provided through Exchange so compatibility is critical.  I’ve not looked into this yet, but I’m guessing there will be some fairly well established solutions available.

Remote Access
Within our PC platform, remote access is provided though a Cisco based VPN solution.  Although some services are also available of web based interfaces, compatibility with this VPN solution will be important for mobile and remote users.

Looking through the Cisco site it looks like there is a client available so hopefully this shouldn’t be a problem.

Authentication
All authentication is provided though Active Directory.  All users have accounts within AD, and where ever possible applications use Windows integrated authentication for sign-on.  To provide an integrated service to the Mac users i think its important that this can be maintained as far as possible – nothing worse than log on prompts interrupting your work!

There’s lots of decent information on this on the Apple site, so pending me reading through it all I’m not too worried about getting this working.