The final session I attended was Deploying & Scaling OCS Group Chat services.
In summary, MS have acquired a product which provides a chatroom facility (similar to IRC), but provides security (AD based) and logging. Whilst does require a separate server to run on than the OCS Messaging server, there is no additional application licensing required.
At present, it does require a separate client, but it does coexist niceley with the OCS client and there is plans to combine the two clients in future.
Some of the examples cited as potential benefit cases is project discussion rooms (because an archive of discussions is made) and global support teams, as members can come online and read the previous 18-24 hours discussions to see what issues/topics were discussed.
-------------------
This is my final blog post from TechEd 2008. See you in Berlin in November 2009!
Friday, November 7, 2008
TechEd 2008, Day 5, 14:45
I attended a session called "A case of the unexplained", presented by Mark Russinovich.
If you've worked with Windows at the technical level for more that a few years, you've probabaly heard of Mark. Or, if not, you've used software he's written. Anything from SysInternals, and much of the stuff in the Resource Kits, he's had a hand in it somewhere.
The session today was demonstrating how to diagnose performance problems, application crashes and the dreaded blue screen of death. There's a useful toolset from MS SysInternals which (when used correctly) can help you identify which software package, even down to which DLL, is causing problems and why.
It's heavy techy stuff, and not something we'd expect lower level analysts to do. It also takes a good deal of time and patience. But if a problem occurs often enough, or is critical enough, there are steps we can take.
If you've worked with Windows at the technical level for more that a few years, you've probabaly heard of Mark. Or, if not, you've used software he's written. Anything from SysInternals, and much of the stuff in the Resource Kits, he's had a hand in it somewhere.
The session today was demonstrating how to diagnose performance problems, application crashes and the dreaded blue screen of death. There's a useful toolset from MS SysInternals which (when used correctly) can help you identify which software package, even down to which DLL, is causing problems and why.
It's heavy techy stuff, and not something we'd expect lower level analysts to do. It also takes a good deal of time and patience. But if a problem occurs often enough, or is critical enough, there are steps we can take.
TechEd 2008, Day 5, 11:45
The session I just attended was called "Connecting your world". Whilst it was mainly aimed at consumer grade people, it demonstrated a lot of the new features in Windows Live and LiveMesh, such as mobile blogging and photo tagging, synchronising files via the cloud (to dekstops and Windows Mobile devices, etc.
They also showed some of the new photo gallery and manipulation tools that Microsoft Labs are producing. Photosynth is already in production, but they are intending to have photo stitching and High-Def stitching and viewing intergrated into Vista very soon. If you want to know more about these, I will no doubt be demoing them to the Mars Photography club very soon.
Final part was a demo of the new features in Virtual Earth, and World Wide telescope, which have both recently been upgraded. For VE, it's mainly US data that has upgraded.
They also showed some of the new photo gallery and manipulation tools that Microsoft Labs are producing. Photosynth is already in production, but they are intending to have photo stitching and High-Def stitching and viewing intergrated into Vista very soon. If you want to know more about these, I will no doubt be demoing them to the Mars Photography club very soon.
Final part was a demo of the new features in Virtual Earth, and World Wide telescope, which have both recently been upgraded. For VE, it's mainly US data that has upgraded.
TechEd, Day 5, 10:15
Just attended a session on Certificate Management in Exchange.
Not much to report - it was predominantly about SSL certificates when publishing Outlook Web Access or Exchange RPC-over-HTTPS. Having our own certificate authority certainly makes it easier!
Not much to report - it was predominantly about SSL certificates when publishing Outlook Web Access or Exchange RPC-over-HTTPS. Having our own certificate authority certainly makes it easier!
Thursday, November 6, 2008
Microsoft TechEd, Day 4, 18:00
Head's starting to spin a little, but I just attended a session called "21st Century Networking: Time to throw out your medieval gateways"
It's an interesting take on the state of network design, and starts off by telling us what we know is true, deep down, but never tell anyone: Network Firewalls are useless.
Because so much traffic tunnels over other ports, or random ports, or malicious code comes in via valid network ports, having a port based firewall is not going to stop stuff getting in or out.
And, nowadays, the operating system itself is reasonably secure. Attacks are coming in via applications and running services, rather than against the OS.
The solution to this is, basically, to retreat: The network, even an internal LAN, chould be considered a hostile place. Get use to it anyway, because IPv6 addresses are globally routable and tunnellable too.
So, to mitigate this, Microsoft recommend dividing client machines into to groups. Manage and Unmanaged.
Unmanaged clients are the PCs/devices beyond the control of the company. Home users, Internet cafes - ones not in the domain. To mitigate against risks from these, using two-factor authentication (Smart cards were the recommended one) and have the user access the corporate servers via MS's Internet Application Gateway software. This gets installed on the application server, and provides an application level firewall which can be modified based on the user's permissions. So, for example, if a user accesses a web page and there's data on the server that the user is not authorised to access, then the gateway filters out that information from the server's responses before allowing the server to client traffic.
Managed clients should have their own local firewall on by default, protecting that client from outside-in access. They should have an X.509 certificates and extensive IPSec policies delivered via Group Policy. Basically, the IPsec policy should contain the IPv6 address of every host in the corporate network (updated by GP every time they boot up), plus the IPv6 address of the corporate DNS server.
Using this method, the client can boot up anywhere in the world, in the company or from home. When the user tries to access a server, the corporate DNS server (which is public facing) provides the IP address. The IPSec policy then kicks in, requiring an encrypted tunnel between the client (using its own X.509 certificate, provided by the domain controller when the client machine joined the domain) and the server it is accessing (which has a certificate signed by the domain controller).
Totally invisible to the end user, and no VPN required at all, and protected against man-in-the-middle-attacks.
The servers, meanwhile, are hardened to only accept traffic coming from clients that are encrypted via IPSec, using valid certificate signed by the domain controller. Therefore, only pre-authorised clients can access them, but from anywhere in the world and with no LAN level firewall required.
As the speaker said: Implimenting this is 99% possible now with Windows software (the only piece missing to de-tunnel tunneled IPv6-over-IPv4 connections, which you can do on Linux but Windows won't have that until early next year).
What is significantly hard to do, is to convince bosses that you don't need a firewall anymore.
It's an interesting take on the state of network design, and starts off by telling us what we know is true, deep down, but never tell anyone: Network Firewalls are useless.
Because so much traffic tunnels over other ports, or random ports, or malicious code comes in via valid network ports, having a port based firewall is not going to stop stuff getting in or out.
And, nowadays, the operating system itself is reasonably secure. Attacks are coming in via applications and running services, rather than against the OS.
The solution to this is, basically, to retreat: The network, even an internal LAN, chould be considered a hostile place. Get use to it anyway, because IPv6 addresses are globally routable and tunnellable too.
So, to mitigate this, Microsoft recommend dividing client machines into to groups. Manage and Unmanaged.
Unmanaged clients are the PCs/devices beyond the control of the company. Home users, Internet cafes - ones not in the domain. To mitigate against risks from these, using two-factor authentication (Smart cards were the recommended one) and have the user access the corporate servers via MS's Internet Application Gateway software. This gets installed on the application server, and provides an application level firewall which can be modified based on the user's permissions. So, for example, if a user accesses a web page and there's data on the server that the user is not authorised to access, then the gateway filters out that information from the server's responses before allowing the server to client traffic.
Managed clients should have their own local firewall on by default, protecting that client from outside-in access. They should have an X.509 certificates and extensive IPSec policies delivered via Group Policy. Basically, the IPsec policy should contain the IPv6 address of every host in the corporate network (updated by GP every time they boot up), plus the IPv6 address of the corporate DNS server.
Using this method, the client can boot up anywhere in the world, in the company or from home. When the user tries to access a server, the corporate DNS server (which is public facing) provides the IP address. The IPSec policy then kicks in, requiring an encrypted tunnel between the client (using its own X.509 certificate, provided by the domain controller when the client machine joined the domain) and the server it is accessing (which has a certificate signed by the domain controller).
Totally invisible to the end user, and no VPN required at all, and protected against man-in-the-middle-attacks.
The servers, meanwhile, are hardened to only accept traffic coming from clients that are encrypted via IPSec, using valid certificate signed by the domain controller. Therefore, only pre-authorised clients can access them, but from anywhere in the world and with no LAN level firewall required.
As the speaker said: Implimenting this is 99% possible now with Windows software (the only piece missing to de-tunnel tunneled IPv6-over-IPv4 connections, which you can do on Linux but Windows won't have that until early next year).
What is significantly hard to do, is to convince bosses that you don't need a firewall anymore.
TechEd 2008, Day 4 14:00
I attended a session on "Exchange 2007 Unified Messaging Component description and overview".
You'd be forgiven for think this was a dry and boring topic because... it was. That was 90 minutes of my life that I will never get back.
You'd be forgiven for think this was a dry and boring topic because... it was. That was 90 minutes of my life that I will never get back.
Microsoft TechEd 2008, Day 4, 11:30
My first session for today was on Co-existence and Migration with Exchange Online.
Most of the session was about provisioning new users and migration from local Exchange. As far as Domino migration goes, there are 3 main strategies:
1) Use IMAP, and only migrate mail - no calendars or contacts
2) Migrate from Domino to Exchange locally first (on a staging server), then migrate up to Online. The speaker cited a US company that did this with 1,000 users in one weekend. Friday night they did the migration from Domino to Exchange, then on the Saturday pushed them up to Online. On the Monday, the majority of users used Outlook Web Access while they did client deployments.
3) Partner with a 3rd party vendor. Apparently, our good friends at Quest are about to release a toolset to migrate from Domino directly to Exchange online.
Most of the session was about provisioning new users and migration from local Exchange. As far as Domino migration goes, there are 3 main strategies:
1) Use IMAP, and only migrate mail - no calendars or contacts
2) Migrate from Domino to Exchange locally first (on a staging server), then migrate up to Online. The speaker cited a US company that did this with 1,000 users in one weekend. Friday night they did the migration from Domino to Exchange, then on the Saturday pushed them up to Online. On the Monday, the majority of users used Outlook Web Access while they did client deployments.
3) Partner with a 3rd party vendor. Apparently, our good friends at Quest are about to release a toolset to migrate from Domino directly to Exchange online.
Subscribe to:
Posts (Atom)
Posts
