09 Mar 2010 @ 6:29 PM 

DirectAccess is a great technology and I love to use it. If I get connection problems, I just open up my command line and examine the ipconfig output to see if something’s wrong. But is this something all your customers and colleagues are capable to do? I think not. Especially in rather large deployments, DirectAccess might put your help desk under a lot of pressure.

To reduce such calls and ease the complexity of debugging actual problems, Microsoft’s DirectAccess Connectivity Assistant might come in handy. It’s a small tool that notifies the user of his current connection status and helps to provide valuable information to the help desk.

So let me show it to you in action.
After setup it will show up in the user’s tray bar.

DirectAccess Connectivity Assistant in traybar

DirectAccess Connectivity Assistant in traybar

A simple single click informs about the current status (as does the tooltip).

DirectAccess Connectivity Assistant balloon

DirectAccess Connectivity Assistant balloon

A right-click offers two options: “Advanced Diagnostics” and a DNS preferation setting (we will come to that later)

DirectAccess Connectivity Assistant right-click menue

DirectAccess Connectivity Assistant right-click menue

The “Advanced Diagnostics” window offers more detailed information about the status and will generate log files upon its launch. Those can be send via the “Email logs” button to a prespecified address. It also has a link to your company’s help desk web page.

DirectAccess Connectivity Assistant Advanced Diagnostics

DirectAccess Connectivity Assistant Advanced Diagnostics

You will need to use the supplied ADMX/ADML files to configure the agent via Group Policy.
To do this, on your Domain Controller, copy the “DirectAccess Connectivity Assistant GP.admx” file to the folder “%systemroot%\PolicyDefinitions” and then copy the “DirectAccess Connectivity Assistant GP.adml” file to the folder “%systemroot%\PolicyDefinititions\language”. For example “%systemroot%\PolicyDefinitions\en-us” or “%systemroot%\PolicyDefinitions\de-DE”.

After that, you can launch the Group Policy Management MMC, open your DirectAccess GPO and navigate to “Computer Configuration / Administrative Templates / DirectAccess Connectivity Assistant”. You can now specify a couple of settings needed to use the tool.

At this point, I would like you to read the Deployment Guide supplied with the download, as it will help you to successfully deploy and configure your Assistant.

Posted By: Christoph Schmidt
Last Edit: 09 Mar 2010 @ 06:29 PM

EmailPermalinkComments (0)
Tags
 25 Nov 2009 @ 9:10 AM 

Computers tend to get slower over time, the more you use it, the faster this will happen. But is this true for hardware as well? In this case: smartcards? I didn’t believe it until I got my hands on a few cards from employees that complained about very slow read times. Our company enrolled smartcards for Direct Access usage (and I love this Windows Server 2008 R2 feature!).

vSEC:CMS Key Tool

vSEC:CMS Key Tool

In the logon screen, it took Windows nearly 45 seconds to read the slowest card and ask for the PIN. Wow! There was no evidence against the card reader, nor the other hardware, as a slow card was slow on all test systems.

But what can you do? Format C! And C stands for “card”. The simplest answers are the best! A short “bing” later, I found a tool named vSEC:CMS Key Tool, provided freely by Versatile Security. With it you can set the smartcard’s PIN and AdminPIN, unblock the user’s passcode and manage certificates. In this particular case, I deleted the original cert and reissued it. And guess what: as good (fast) as new!

Posted By: Christoph Schmidt
Last Edit: 25 Nov 2009 @ 09:10 AM

EmailPermalinkComments (0)
Tags
Tags: ,
Categories: Security, Tools
 22 Nov 2009 @ 12:52 AM 

A Microsoft Sharepoint Server can be very complicated, to say the least. Last week I had the task to establish Kerberos authentication throughout a very small Sharepoint environment, consisting just of a MS SQL 2008 Server and the Office Sharepoint Server itself. The installation was based on Microsoft’s best-practice recommendations, so every application pool and Windows service  had it’s own domain user.

Looking up all interesting data can take some time, especially if you did not setup these servers yourself. I stumbled upon a small tool that gathers useful data about Office Sharepoint and Sharepoint Services environments. It is called SPSFarmReport and is an open-source project at Codeplex.

The following “questions” will be answered by the tool: 

  • How many servers exist in the farm?
  • What services are run by each server in your farm? Which server is the Query/Indexer?
  • Which server(s) host(s) the Central Administration web site in the farm?
  • How many SSPs exist in the farm?
  • Which is the default SSP in the farm?
  • What is the URL of the administration site of an SSP?
  • What is the URL of the My Site provider of an SSP?
  • What Web applications are associated with each SSP?
  • Which application pool is associated with each web application in the farm?
  • Which account is used to run a specific application pool?
  • How many content databases are associated with each web application and how many site collections does each have?
  • What AAMs are configured for each web application?

You run it on one of the Sharepoint servers and it will gather all the data from there and create an HTML result file.

It really helped me to get an overview and locate all the accounts I had configure for Kerberos.

Get it here: http://www.codeplex.com/SPSFarmReport

Posted By: Christoph Schmidt
Last Edit: 25 Nov 2009 @ 09:10 AM

EmailPermalinkComments (0)
Tags
Tags: , , , , ,
Categories: Sharepoint, Tools
Change Theme...
  • Users » 1
  • Posts/Pages » 14
  • Comments » 3
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight

About



    No Child Pages.

Disclaimer



    No Child Pages.