Sunday, February 28, 2010

Update - Windows 7 - Microphone control - where is it?

Ok, now that I have the RTM of Windows 7 installed I realized they have changed the microphone controls and made it a bit easier but still confusing. So, here are some screenshots with a brief write up so you can find it. Crazy frustrating for those of us who do livemeeting, gotomeeting and webex stuff on a regular basis!

You will need to right mouse click on the speaker icon in the taskbar in the lower right and it will pop up a menu option. The third one down is "Recording devices" - select this one.


From there it will pop up a "Sound" window - pick the second tab which is "Recording" and it should display a microphone. Highlight it and then pick properties in the lower right of the window.


When that window pops up you will finally be able to adjust the properties of the microphone. You will need to go to the third tab labeled "Levels" in order to set the microphone gain or adjust it at all with the exception of muting, sort of. Even though it is shown muted in this window if you use the "Volume Mixer" window it will not display it as "muted!" but it is actually muted. Am I the only one confused here?


You get to the Volume Mixer window by left mouse clicking on the speaker in the lower right of the task bar and selecting "Mixer." It will pop up a window that shows all your current speaker and microphone devices as shown. I have selected to mute it here and if I toggle it back and forth it does what I expect but it does not match what is in the Microsoft Properties tab! I think that is a bug.


Glad they made it a bit easier to at least mute the microphone but weird that the two items don't display the same "state" for the microphone.
- Ed

Saturday, February 27, 2010

Windows 7 RC warnings - time is up

Less than two days and counting until things start getting ugly for those running the Windows 7 RC still. I just spent the day doing a fresh install of Windows 7 so I am in the clear now. Just so you know, if you are seeing the following you are still on the RC:



So take the time to get your legit copy of Windows 7 and do a clean install!
- Ed

Thursday, February 25, 2010

How the Microsoft MVP program uses the three elements of motivation from Drive

I've been pondering the key area's of Daniel Pink's newest book Drive: The Surprising Truth About What Motivates Us and I think Microsoft indirectly has stumbled upon the key three elements of true motivation as defined in Daniel's book which are autonomy, mastery, and purpose. For those that are skeptical hold on and see if I might be onto something.

One of the key principles of the Microsoft MVP program is the fact that the award is given to independent experts who are actively involved in community, you can see more about the program here. Microsoft is leveraging via the MVP award those that are independent from Microsoft yet give back in both time and energy to make Microsoft products and technology better. Microsoft MVP's experience the ultimate in autonomy, they don't work for Microsoft and are therefore free to say and express what they want about Microsoft's products and technologies with a few NDA exceptions. By Microsoft expressing their appreciation of these individuals they are tapping into one of the key motivations and what drives many Microsoft MVP's - autonomy in what they say but third party validation of the quality of what they are saying. In other words, what Microsoft MVP's have to say is worth listening too.

To quote a portion of the Microsoft MVP site "MVPs make exceptional contributions to technical communities, sharing their passion, knowledge, and know-how." Many within the IT Professional and Developer community consider Microsoft MVP's to be experts within their respective field. Microsoft naturally is awarding those they think are at the top of their game but I believe the Microsoft MVP award pushes those who have been awarded to meet an even higher standard. Indirectly, Microsoft nurtures the motivation of mastery within their MVP community which make their program even better. After returning from the Microsoft MVP Summit I can honestly say I am motivated to work harder and do more, I'm always impressed by the caliber of individuals I meet at the summit each year. Feeling like there is always more to learn, more to do, more skills to work on seems an ever present mantra within the Microsoft MVP community and this directly relates to mastery.

Finally, purpose. I think almost all MVP's feel a connection to community in what they do. MVP's are purpose driven animals who love to share, teach and pass on the information they have learned with others. I think that is one of the most impressive aspects of those who are awarded. When you look at the total number of people Microsoft MVP's have direct and indirect influence on no wonder Microsoft is interested in nurturing a unique relationship with their MVP's.

I by no means want to toot my own horn, there are plenty of Microsoft MVP's out there that do a far superior job in all areas than I but after reading Daniel Pink's book I really felt it struck home how I feel about the Microsoft MVP program. So, in many ways I believe Microsoft has started to utilize the principles in Drive - it would be interesting to know if those on the inside of Microsoft feel the same way about being an employee there.
- Ed


Monday, February 22, 2010

IPv6 design and deployment considerations for Microsoft's DirectAccess

One on the unique aspects about DirectAccess is the requirement of IPv6 for accessing internal resources. It requires that IT Pros get a lot more familiar with IPv6 and how and why they need to deploy it within their environment.

Much of Microsoft's current design guides and recommendation revolve around proof of concept deployments and not final design deployment models. I want to address that gap and give IT Pros some things to consider when discussing with their network teams the implementation of IPv6 they require for the POC vs what the final design might look like.

Currently Microsoft offers two main methods for internal IPv6 access methods within their design guides, the first is a transition technology called ISATAP and the second is to utilize Native IPv6. While ISATAP is a functional transition technology I believe it has several pitfalls that a POC overlooks and perhaps give a false impression of the potential deployment scenarios that might be supportable long term in an environment. First, since ISATAP is a tunneling technology and effectively looks like an overlay network it can be difficult to troubleshoot access problems. In addition, there are no specific management or monitoring tools for ISATAP requiring IT Pros to know all the areas where ISATAP could potentially have problems and how to diagnose it, I find that a tall order for many IT Pros given the general lack of knowledge regarding IPv6.

To top it off, ISATAP has an implicit sunset mechanism (if you host sees a Native IPv6 address it will use that first), it's really design to transition your network to Native IPv6, so the question I pose for IT Pros is:
Why not start with Native IPv6 and bypass these issues?

So what is involved with getting a Native IPv6 deployment working? There are several options available to start using native IPv6. Likely the easiest is to use a tunnel broker like Hurricane Electric to bring up a Native IPv6 network address range at you IPv4 location. Once you have this in place you have plenty of Native IPv6 address space to utilize in your network. The next logical step is to get full Native IPv6 transit services from a provider. With Comcast's recent announcement's around IPv6 and long standing IPv6 providers like Hurricane Electric there are options for both Enterprises and small businesses now.

I think serious consideration should be given to deploying Native IPv6 services as the solution for DirectAccess. It allows the greatest flexibility long term and avoids many of the pitfalls that may happen with an ISATAP deployment. I look forward to seeing if others feel differently.
- Ed

Thursday, February 18, 2010

Quick update on Microsoft Teredo

I got my chance to meet with Joe Davies (CableGuy) with Microsoft yesterday and outline my items regarding Teredo. He is going to follow up with Sean Siler and others regarding the behavior of Teredo, the ability to manage Teredo and what exactly is collected (if anything) at teredo.ipv6.microsoft.com.

So, as soon as I hear back from Joe and Sean I will put up a post (assuming it isn't NDA) and hopefully clear up some of these items.

I also had a bunch of questions regarding ISATAP and what Microsoft has for a roadmap in terms of support and deployment around ISATAP. I've expressed my distaste for ISATAP due to the lack of management tools for it to determine where issues are within your network. That being said, I asked specifically for a written policy and guide around ISATAP so hopefully we will get something!
- Ed

Wednesday, February 17, 2010

Should Microsoft have a different policy on the default behavior of their Teredo client?

Now with Windows 7 increasing in deployments there is a legitimate concern if Microsoft has the best policy regarding non domain joined client machines having Windows Teredo enabled but not active as a default setting. There are many forum and security posts saying that even minor changes in the OS activate the Teredo client service turning it on and enable it. While the new Advanced Firewall certainly is IPv6 ready and had a good default posture it concerns many people that the Teredo client is going out to teredo.ipv6.microsoft.com automatically and obtaining a legitimate routable IPv6 address.

I personally have not seen this behavior on Windows 7 clients I have used but I tend to use clients that are joined to a domain and are not stand alone clients. The behavior of non domain joined machines seems to be different then domain joined ones and this is likely to address the home/smb market and the different behavior that Microsoft wanted those people to experience than an Enterprise deployment.

For Enterprise and SMB's that are a concerned about client machines accessing Microsoft's Teredo relay server it is easy enough to write a GPO that would disable the teredo client, I covered much of the commands to do this in a previous post. What is more interesting from a security standpoint is if someone is able to exploit a client and then turn on the teredo service to register the client machine via IPv6 to a third party Teredo relay. They could easy pass all the command control portions over IPv6, have unfiltered access to the machine and have unrestricted access to many networks behind commercial firewalls providing NAT/PAT services.

I hope the days of people thinking that NAT/PAT devices provide any security are quickly at an end (finally) due to the transition technologies like Teredo that make bypassing a NAT/PAT device just way to easy. All the major torrent services use similar methods so anyone who thinks you can't share content this way is ignoring the facts. Application aware firewalls and host based firewalls are the only way to control traffic now. Microsoft has done the first step to address this with the Advanced Firewall and AD GPO policy pushes. They are introducing the second phase next with their Forefront client software suite to allow even more management and policy options through System Center. I think this will be critical for enterprises, especially those that are adopting virtualization and remote desktop configurations.

So, what are the benefits of running Teredo services? Why would Microsoft have enabled the service and let applications decide when they need unfettered access to the IPv6 network? I believe it is to address the needs of home users trying to connect multiple devices behind NAT/PAT home consumer grade network devices (Linksys, Netgear and the like) and then wanting to share the content and access their network from the public Internet. While perhaps this is awhile off in terms of a common deployment many companies are already providing similar services. Slingbox, GoToMyPC, torrents, and other file sync sites all could leverage Teredo and IPv6 to make the process work easier than it current is doing today. Instead of having a central proxy control server hosts could be directly connected with the home or work host they need content from, a novel idea. In addition, a machine could have a consistent IPv6 address all the time via the Teredo server regardless of what IPv4 network it is on, not a bad function in terms of getting content from a host and knowing you have the right one.

What I am not happy with is the lack of any intuitive interface within the GUI to tell you if Teredo is actually on or not. There is no way outside of command line that I am aware of to know if Teredo is enabled. It would seem like a simple enough process to add a small control applet to let people know if Teredo is enabled/disabled and if it is currently being used or not. This would go a long way to allowing folks to control this basic transition service.

I guess I will ask what Microsoft was thinking regarding this while I have their ear over the next few days and report back.
- Ed

Tuesday, February 16, 2010

Microsoft MVP 2010 Summit begins!

This morning is the first day of formal Microsoft MVP Summit activities. It is in a new location (Bellevue) for the off campus portion and even the on campus central drop off and pick up is in a new location. I'm happy about the new location for the campus since it is super close to the company store so it will be easier to pick up a few gift items for friends back home.

I'm looking forward to hearing about all the new stuff Microsoft is up to although I think the Windows Mobile folks will be capitalizing a bunch of stuff with the launch of Windows Mobile 7 yesterday. I'm sure it will be all the buzz everywhere.

Look forward to seeing a bunch of fellow MVP's over the week, sorry if I don't post a bunch during the week but there is a lot going on here.
- Ed

Monday, February 15, 2010

Why you should consider building your entire network assuming guestnet access

I believe for many SMB and enterprise networks it makes sense to evaluate what you are providing to you staff, how you are providing it and why. With the recent shift to wireless and cloud services it is time to reevaluate that again.
With wireless becoming an expected service at all enterprise location and for some SMB's the only access it makes sense to be able to authenticate who the user is prior to granting them access to the network. With 802.1x it is possible to do this with an open standard that has cross vendor support. Having this basic functionality in place allows for the possibility of providing guestnet services automatically (self provisioned or pre-defined.)

The next logical question is, should you be authenticating on wired ports also to provide the exact same services with the same posture and guestnet ability. I would argue a case for this and from a posture and security standpoint say that if you are doing it for wireless but not wired your wireless is more secure than you wired implementation. Would love to hear thoughts on that one.

By mixing cloud services (host mail, wiki or portal access, file storage) with guestnet and authenticated access you can provide services to your end users regardless of network topology assuming the network is providing Internet access.

To add to the benefit, you can do remediation and fix machines that don't meet certain posture profiles if you wish to go that far. That means utilizing a more robust solution like Microsoft NAP or Cisco NAC or using a solution that can leverage both like Avenda.

With all this available today it makes sense to plan the whole network infrastructure such that guestnet and authenticated network access is done everywhere. There might be exceptions, your data center core, dmz, storage and edge networks may not require the same services but should likely have port security at a minimum as you are unlikely to be moving servers or network devices around once an initial deployment is done.

Some food for thought in the network design area, maybe some design changes are in order?
- Ed

Friday, February 12, 2010

Follow up from last night's EBCUG - IPv6 and Teredo

At last nights EBCUG meeting there was a very lively debate regarding Microsoft and Teredo and what the OS's are and are not doing by default with Teredo. To clear up some of the items I wanted to provide some links and information.

First, Microsoft has some pretty good write ups on IPv6 and Teredo specifically and what they have implemented. As you can see on the Teredo page they specifically outline when IPv6 and Teredo are enabled by default and when they are not. The Teredo write up is quite extensive and goes over all the methods for NAT traversal. You can also find a good transitions document from Microsoft regarding all the IPv6 transition technologies. To clear up what is and is not on by default the document says the following:
"Teredo support is included and is disabled by default. Teredo support is included with Windows Server 2008, Windows Server 2003 Service Pack 1 and later, Windows XP with SP2 and later, and Windows XP with SP1 and the Advanced Networking Pack for Windows XP, and is disabled by default. Teredo support is also included with Windows Vista and is enabled but inactive by default. "

For those with Windows XP SP2 that are concerned about running Teredo the Windows Firewall does protect against unsolicited incoming IPv6 traffic just like for IPv4. To set up Teredo on Windows XP SP2 you need to install IPv6 with the netsh interface ipv6 install command and then enable Teredo with the netsh interface ipv6 set teredo client command. But by default Teredo is not enabled on XP.

For Windows Vista and 7 (and Windows Server 2008 and 2008R2) it is possible to disable IPv6 (not uninstall it) by using the instructions at this KB article.

If you are running Windows Vista, 7 or Server 2008 then switch to powershell commands. If you want to see what Teredo is doing you can issue under powershell netsh interface teredo show state which should have output something like:
PS C:\> netsh interface teredo show state
Teredo Parameters
---------------------------------------------
Type : client
Server Name : teredo.ipv6.microsoft.com.
Client Refresh Interval : 30 seconds
Client Port : unspecified
State : offline
Error : client is in a managed network

You can also use the netsh interface ipv6 show teredo powershell command to see the same information.

If you want to set the state for Teredo you can do netsh interface teredo set state disabled to turn off Teredo. Sample command parameters are:
PS C:\> netsh interface teredo set state ?

Usage: set state [[type]=disabled|client|enterpriseclient|server|default]
[[servername=]||default]
[[refreshinterval=]|default]
[[clientport=]|default]
[[servervirtualip=]|default]

Parameters:

Tag Value
type - One of the following values:
disabled: Disable the Teredo service.
client: Enable the Teredo client.
enterpriseclient: Skip managed network detection.
server: Enable the Teredo server.
default: default state is client.
servername - Name or IPv4 address of the Teredo server.
refreshinterval - Client refresh interval (in seconds).
clientport - Client's UDP port (otherwise chosen by system).
servervirtualip - IPv4 address of the server virtual ip.
Not applicable if running as teredo client.

Remarks: Sets Teredo state.
A 'default' argument to a parameter sets it to the system default.
The 'type=server' option only works on server skus.

Examples:

set state disable
set state client teredo.ipv6.microsoft.com 60 34567

For a lot more details about the netsh commands check out this Technet Library entry.

It is true that the default Teredo servername parameter is set to teredo.ipv6.microsoft.com which is actually a CNAME which points to teredo.ipv6.microsoft.com.nsatc.net. which resolves to 65.55.158.80. If you are truly concerned about any hosts on your network building out Teredo services to Microsoft without your knowledge simply block traffic to that IP address. You can also optionally poison the DNS name in your local name servers.

For IT professionals running AD you can set up a GPO to disable Teredo though I believe by default Teredo will stay in a disabled state if it sees that your machine is domain joined.

Hope that helps clear up and provide some resources on Teredo. It was a great meeting and very interesting talking to everyone about IPv6 and what is happening with it.
- Ed

Microsoft MVP 2010 Summit

I am flying up to attend the Microsoft MVP 2010 Summit on Monday which is being hosted in Bellevue and Redmond, WA. I am looking forward to seeing fellow MVP's again, getting to meet new MVP's and participating in sessions and interaction with a lot of the Product Managers. It is always amazing how much stuff is packed into the 4 days, plus all the side sessions and private one on one meetings that seem to just happen.

I will update what I can that isn't under NDA which is sometimes a struggle at this event given the amount of material discussed.
- Ed

Thursday, February 11, 2010

EBCUG Meeting tonight - IPv6

Tonight is the East Bay Cisco User Group meeting in Pleasanton at the Cisco office and they are having Owen DeLong present who is an IPv6 Evangelist for Hurricane Electric. It should be a good meeting as he is going to cover all sorts of IPv6 related items and hopefully talk some about how HE.NET implemented their deployment of IPv6. HE.NET has been an early adopter of IPv6 and they run a great free tunnel broker service at tunnelbroker.net which I encourage people to use to get test deployments of IPv6 done. The ebcug site has an rsvp, hope to see you there.
- Ed

Monday, February 08, 2010

Pacific IT Professionals - Microsoft SIR and Terminal Services presentations

I got to present at the last Pacific IT Professionals meeting at Microsoft's office in San Francisco about network edge filters. The presentation was a summary of my Bogon blog post plus using the RFC's for network edge filtering so nothing new. The slide deck was mainly a single diagram to have a talking point to generate discussion. You can get the deck here at the PacITPros website.

It was nice to present but there were two excellent presentations worth mentioning that happened at the same meeting. The first was from Joanie Rhine with Microsoft regarding Microsoft's Security Intelligence Report (SIR) and an overview of it's results, the presentation is available on the PacITPros website here.

The second was a Terminal Services presentation by Jennelle Crothers that is really good, talks about replacing Citrix with a simple Microsoft only solution and some of the challenges and differences there are between the two. You can find that presentation at the PacITPros website also, here.

Sorry for the delay on the blog post about the meeting, I managed to get a horrible cold that knocked me out for a few days. Put a damper on updating the site.
- Ed

Tuesday, February 02, 2010

How to prevent ipv6 tunneling across firewalls and routers

Perhaps it is a company policy or someone on your IT team feels it is important to block IPv6 tunneling across your network to 6to4 relays or Teredo relay servers or perhaps you only want internal folks using your delegated IPv6 address block. Do you have any options available to you to block this sort of traffic?

As it seems with all things tech related the answer is, it depends on what you want to do. Both 6to4 and ISATAP utilize IPv4 protocol 41 to tunnel their traffic. Therefore, it is easy enough to block IPv6 protocol 41 from traversing internally (which would stop ISATAP and 6to4) or at the edge firewall (which would stop 6to4 but might not stop ISATAP.) On Cisco IOS it might look like this on an internal router or switch:
access-list 100 deny 41 any any
access-list 100 permit any any (or whatever traffic you DO want to permit)

In addition, to this step you can blackhole the IPv4 route to 192.88.99.1 which is the IPv4 anycast address used for the 6to4 IPv4 relay. On Cisco IOS you could do:
ip route 192.88.99.1 255.255.255.255 null0

Teredo clients can be blocked in a simple method because by design it utilizes UDP over IPv4 to establish and build it's NAT traversal tunnel traffic. Simply blocking outbound UDP traffic solves the problem but certainly breaks a lot of other functions for end client machines.

If you are running a Microsoft Windows AD configuration with clients belonging to the domain you can poison the Teredo entry that is used by default on a Microsoft client machine. All Microsoft clients from Windows XP on up make use of the dns name teredo.ipv6.microsoft.com to resolve if they can utilize Teredo to build out an IPv6 connection. This likely isn't the best method but it can be effective and some might say required because from Windows Vista on up Teredo is enabled by default but is inactive. This means if an application gets installed that wants to make use of Teredo it activates the Teredo client and attempts to use it.

You can also use a GPO to change the registry keys to keep Teredo off. You can push firewall changes to the Windows clients (Vista and Windows 7) that would block Teredo or you could turn off IPv6 which would solve the problem also. Microsoft has documentation on all of those options, you can start looking here, here or here to find out more.

So, in those cases where you actually need to turn off IPv6 tunneling technologies there are options available. The next question is do you really want to block these technologies?
- Ed