Home - Gilham Consulting Microsoft Notepad

7/3/2009

California Updates Corporate E-Discovery Rules

Arnold signs new legislation on standardizes e-Discovery rules for California companies.

…
With the now near-universal business use of e-mail, the Internet, data storage and text messaging, e-discovery has grown into a large and costly sector of litigation. The 2008 Socha-Gelbmann Survey estimated that commercial spending on electronic data discovery topped $2.7 billion in 2007.
"The California Discovery Act hadn't really been revised or amended since the mid-1980s," said Patrick O'Donnell, the supervising attorney for the Judicial Council's Office of the General Counsel who led efforts to write the state's e-discovery law. "This is really a major step to address the changes in the world of electronic data since then. ... This gives a lot more clarity and certainty in how the issue will be focused on."
California's new rules represent a compromise between trial lawyers, who wanted greater access to electronic records, and defense counsel and high-tech companies, who wanted protection for data they say is too costly or too difficult to produce. State law — again, much like federal law — will allow respondents to object to producing records they deem inaccessible so long as they specify the category of information they're trying to protect. That protection was a crucial element in securing tech companies' support for the bill.
…

Read the complete article @> Law.com - State Finally Updates E-Discovery Rules

Posted at 12:14 PM by John Gilham | Category: IT Management | Permalink | Email this Post | Comments (0)

6/30/2009

Server Migration Made Easy With Microsoft File Server Migration Toolkit 1.2

Jose Barreta posts this great find:

Microsoft released the File Server Migration Toolkit version 1.2 (FSMT 1.2), which will help you migrate file shares from computers running Windows NT 4.0 Server, Windows 2000 Server, Windows 2003 Server, Windows Server 2008 and Windows Storage Server 2008 to computers running Windows 2003 Server, Windows Server 2008 and Windows Storage Server 2008. You can use it to consolidate multiple file servers or simply to migrate files between servers.
This is an update to the previous FSMT 1.1 that fixes an issue with Windows Server 2003 clusters. This version has also been tested with the Windows Server 2008 R2 Release Candidate (full support for Windows Server 2008 R2 is expected and will become official after tests with the final release, which should be out later this year).
Here are the main benefits of FSMT:

Simplifies the complex and error-prone migration process of SMB shares and data
Maintains UNC paths and eliminates broken shortcuts and links
Maintains security settings after the migration
Consolidates shared folders with the same names from different servers
Supports server clusters as source and target file servers
Provides roll-back functionality
Support for Windows Server 2008 and Windows Storage Server 2008
Includes both the DFS Consolidation Root Wizard and the Dfsconsolidate.exe command-line tool
Available in 5 languages (English, French, German, Japanese and Spanish)

Here’s a screenshot:

Download and test it today from
http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en
Also, be sure to also visit the FSMT Web Site at
http://go.microsoft.com/fwlink/?LinkId=128527

The Storage Team at Microsoft - File Cabinet Blog : Microsoft File Server Migration Toolkit 1.2 available as a free download

Posted at 8:43 AM by John Gilham | Category: Windows Storage | Permalink | Email this Post | Comments (0)

Automating Windows Server Deployment SCVMM Sample Unattend.XML for Windows Server 2008 R2

In today’s post, I thought I would share with you some XML that drives some of our dynamic provisioning. The power of dynamic provisioning is found in taking a base image of a Server operating system that has nothing enabled and customizing it using the Windows Automated Installation Kit (WAIK) that is available in SCVMM.
Getting Started with Unattend.XML

The officially supported method of building unattended files for Windows Server 2008 & R2 is using the Windows System Image Manager that is part of the WAIK. I will follow that party line and say this is the method you should go about building your unattended file though I can say that I haven’t followed this “support” method and have used my trusty Visual Studio editor and the WAIK unattended documentation. This should be considered your warning and please don’t punish me if you do this. <grin>
With this said, you could start with this unattended.xml file and build upon it and let me teach you how to do this though, again, it is not the recommended approach.
Get Started: Build your Base Unattended XML

You should open your favorite XML editor and start with this as your base.
Code Snippet

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
      <Display>
        <ColorDepth>16</ColorDepth>
        <HorizontalResolution>1024</HorizontalResolution>
        <RefreshRate>60</RefreshRate>
        <VerticalResolution>768</VerticalResolution>
      </Display>
      <RegisteredOrganization>Contoso</RegisteredOrganization>
      <OOBE>
        <HideEULAPage>true</HideEULAPage>
        <NetworkLocation>Work</NetworkLocation>
        <ProtectYourPC>1</ProtectYourPC>
        <SkipMachineOOBE>true</SkipMachineOOBE>
        <SkipUserOOBE>true</SkipUserOOBE>
      </OOBE>
   </component>
</settings>
</unattend>

This is a basic unattend that will do the following:

Set your background to 16-bit color
Set your resolution to 1024x768 with a refresh rate of 60
Set your organization name to Contoso
Hides the EULA
Sets network location to Work
Sets the automatic settings for Security
Disables the Windows Machine Out-of-box-Experience

This is a good place to start. The key thing to note is that the only piece of the <component> line that changes is the name=” “ section and the name is easily identifiable through the documentation. Let’s, say for example you wanted to set the proxy settings in your unattended file you would search the documentation and you would find -
You simply copy an existing <component> line and you change the name=” “ to whatever setting you desire and you are off.

Some rumblings from the weeds of Microsoft... : SCVMM Sample Unattend.XML for Windows Server 2008 & R2

Posted at 8:41 AM by John Gilham | Category: Windows Deployment | Permalink | Email this Post | Comments (0)

Implementing a OCSP Responder for Certificate Services in Windows 2008

Chris here again. For those Security Architects and PKI implementers, you may have known that since Windows Server 2008 we have an Online Certificate Status Protocol (OCSP) responder, and since Windows Vista we have an OCSP client that is integrated with the operating system. I wanted to cover the in and outs of the OCSP responder, and walk through the installation.
So, you may be asking the question “OCSP what?” First a little background. One of the capabilities of a PKI and in particular a Certificate Authority, aside from issuing certificates, is to publish revocation information.
For example, let’s say you issue a User certificate to a user for authentication. When the user leaves the company you will most likely want to make sure no one can use that certificate for authentication so you log onto the Certificate Authority and revoke that certificate. Each CA has a period specified when it publishes what are called Certificate Revocation Lists or CRLs for short. When the next CRL is published it will contain the serial number of the certificate, the date and time it was revoked, and the reason that the certificate was revoked. Depending on the configuration the CA it will publish the CRL to a repository such as an LDAP server or a web server. In some instances a task or job must be created to copy the CRL to a repository.
Aside from CRLs, there are also delta CRLs. Delta CRLs simply contains the revocation information for certificates that have been revoked since the last Base CRL was published. In order to determine revocation status an application would examine the last base CRL, and the latest delta CRL. The reason for publishing delta CRLs is to provide revocation information that has more current data. Also, it can reduce bandwidth since if the base CRL is already cached on the client, just the delta CRL can be downloaded. More on this later.
In order for applications to determine if a certificate has been revoked, the application examines the CRL Distribution Point (CDP) extension in the certificate. This extension will have information on locations where the CRL can be obtained. These locations are normally either HTTP or LDAP locations.
The application then can go to those locations to download the CRL. There are, however, some potential issues with this scenario. CRLs over time can get rather large depending on the number of certificates issued and revoked. If CRLs grow to a large size, and many clients have to download CRLs, this can have a negative impact on network performance. More importantly, by default Windows clients will timeout after 15 second while trying to download a CRL. Additionally, CRLs have information about every currently valid certificate that has been revoked, which is an excessive amount of data given the fact that an application may only need the revocation status for a few certificates. So, aside from downloading the CRL, the application or the OS has to parse the CRL and find a match for the serial number of the certificate that has been revoked.
With the above limitations, which mostly revolve around scalability, it is clear that there are some drawbacks to using CRLs. Hence, the introduction of Online Certificate Status Protocol (OCSP). OCSP reduces the overhead associated with CRLs. There are server/client components to OCSP: The OCSP responder, which is the server component, and the OCSP Client. The OCSP Responder accepts status requests from OCSP Clients. When the OCSP Responder receives the request from the client it then needs to determine the status of the certificate using the serial number presented by the client. First the OCSP Responder determines if it has any cached responses for the same request. If it does, it can then send that response to the client. If there is no cached response, the OCSP Responder then checks to see if it has the CRL issued by the CA cached locally on the OCSP. If it does, it can check the revocation status locally, and send a response to the client stating whether the certificate is valid or revoked. The response is signed by the OCSP Signing Certificate that is selected during installation. If the OCSP does not have the CRL cached locally, the OCSP Responder can retrieve the CRL from the CDP locations listed in the certificate. The OCSP Responder then can parse the CRL to determine the revocation status, and send the appropriate response to the client.

Read the rest @>
Implementing an OCSP responder: Part I Introducing OCSP
Implementing an OCSP responder: Part II Preparing Certificate Authorities
Implementing an OCSP responder: Part III Configuring OCSP for use with Enterprise CAs
Implementing an OCSP responder: Part IV Configuring OCSP for use with Standalone CAs

Posted at 8:12 AM by John Gilham | Category: Active Directory | Permalink | Email this Post | Comments (0)

6/29/2009

DFS Replication on a Windows 2008 Failover Cluster

Mahesh Unnikrishnan posts:

On Windows Server 2008 R2, a Windows Failover cluster can be configured to be a member of a DFSR replication group. This feature can be used to configure highly available replication services. In this three part blog series, let us examine how to configure a Windows Failover cluster as a DFS Replication member server. For a quick recap of the new features in DFS Replication on Windows Server 2008 R2, head here.
The first step is to validate the available hardware that will be used for clustering and to create a Windows Failover Cluster. The next post in this series covers the steps required to configure high availability for the DFS Replication service. The third and final post in this series covers the steps required to add the failover cluster to a replication group.
Deployment Scenario
Before we start, let us examine the deployment scenario for which we are creating this failover cluster. In order to implement a highly available replication infrastructure, Contoso plans to deploy a 2-node failover cluster at it's datacenter site/main office. This failover cluster is part of a DFSR replication group. DFS Replication is used to consolidate data to the datacenter server from multiple branch office file servers for centralized backup using backup software such as Microsoft System Center Data Protection Manager. As shown in the above figure, the failover cluster to be setup at the datacenter location consists of two nodes – servers named ‘PrimaryNode’ and ‘SecondaryNode’ respectively. The servers are both connected to shared storage. If the PrimaryNode were to encounter hardware failures, the Windows Failover Clustering service should automatically failover replication responsibilities to the SecondaryNode without having to reconfigure the DFS Replication service on any of the branch office file servers (replication partners).
In this series of blog posts, let’s explore the steps required to configure and set up such a failover cluster, configure DFS Replication for high availability on that cluster and then finally add the failover cluster to a replication group.
<snip>

Read the rest @> The Storage Team at Microsoft - File Cabinet Blog : Deploying DFS Replication on a Windows Failover Cluster – Part I

Posted at 9:17 AM by John Gilham | Category: Windows Storage | Permalink | Email this Post | Comments (0)

6/24/2009

Active Directory and Active Directory Domain Services Firewall Port Requirements

Applies To: Windows Server 2000,Windows Server 2003,Windows Server 2003 R2,Windows Server 2003 with SP1,Windows Server 2003 with SP2,Windows Server 2008,Windows Server 2008 Foundation,Windows Server 2008 R2,Windows Vista

This guide contains firewall TCP/IP port requirements for various Active Directory® and Active Directory Domain Services (AD DS) components.

<snip>

Windows Server 2008

In a mixed domain environment, you have to open the ports in the following table as well as the ports in the Windows NT, Windows 2000 Server, and Windows Server 2003 tables in the “Trusts” section of this document.

Note

For more information about the change in the dynamic port range in Windows Server 2008, see article 929851 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=153117).
You can find additional information about this change on the Ask the Directory Services Team blog. See the blog entry Dynamic Client Ports in Windows Server 2008 and Windows Vista (http://go.microsoft.com/fwlink/?LinkId=153113).

Client port Server port Type of traffic

TCP Dynamic

TCP 135, 49152–65535

RPC, EPM

TCP and UDP Dynamic

TCP and UDP 389

LDAP

TCP Dynamic

TCP 636

LDAP SSL

TCP Dynamic

TCP 3268

GC

TCP Dynamic

TCP 3269

GC SSL

TCP and UDP 53, Dynamic

TCP and UDP 53

DNS

TCP and UDP Dynamic

TCP and UDP 88

Kerberos

TCP and UDP Dynamic

TCP-NP and UDP-NP 445

Security Accounts Manager (SAM), LSA

TCP Dynamic

UDP 138

NetBIOS Datagram Service

Read the rest @> Active Directory and Active Directory Domain Services Port Requirements

Posted at 1:56 AM by John Gilham | Category: Active Directory | Permalink | Email this Post | Comments (0)

Microsoft RDP 7+ Protocol Includes Remote GPU Acceleration

Earlier this week I wrote about about Microsoft’s last minute change to RDP in Windows 7, where all DirectX components will now be rendered on the host. I based my post on an MSDN blog post by Microsoft employees Christa Anderson, Gaurav Daga, and Nelly Porter.
In the comments of the original MSDN post, reader David Rottenberg wrote that this change was a bad idea, partially because host-side software-based DirectX rendering would be slow. Microsoft’s Guarav Daga’s response included:

As for running DirectX applications on Windows Server 2008 R2 Hyper-V virtual machines, there will be the GPU offload hardware assist Calista technologies at some point in the future.

<snip>

Read the rest @> Microsoft’s RDP host-side rendering (Calista) plans include optional GPU offload hardware & custom chips. (Oh, and Hyper-V is required!) - Brian Madden - BrianMadden.com

Posted at 1:37 AM by John Gilham | Category: Terminal Services | Permalink | Email this Post | Comments (0)

6/23/2009

Introducing the DirectAccess solution for Microsoft Forefront UAG

Nitzan Daube. PM for UAG posts:

As the PM lead responsible for the UAG DirectAccess, I’m proud to present our solution based on the new and exciting technology introduced by Windows 7 Direct Access. If you want to learn more about this technology click here.
Microsoft Frorefront Unified Access Gateway (UAG) utilizes DirectAccess technology built into Windows 7 and Windows Server 2008 R2 to create an enterprise level solution. UAG offers an all in one, end-to-end solution that lets the enterprise open its resources to managed clients in a seamless, painless manner.
UAG DirectAccess extends access to IPv4 servers

In order to support all backend servers, UAG DirectAccess adds a necessary transition technology (NAT64 and DNS64 also known as NAT-PT and DNS-ALG) to also allow clients access to IPv4 only servers – in addition to IPv6 based servers (natively or via ISATAP).
UAG DirectAccess enhances scalability, high-availability and management

Our solution adds the ability to scale and have multiple Direct Access Servers (DAS) in a cluster for providing high-availability of the service as well as scale-up. As part of ‘all in the box’ paradigm, UAG integrates Windows Network Load Balancing (NLB) support that could be seamlessly activated for the cluster.
UAG DirectAccess simplifies deployment and administration

We incorporated and augmented the DirectAccess configuration into its Unified Access Gateway management console allowing an easier deployment of the cluster. The console will help you setup, configure, activate and manage the cluster and each node in it from a central location. This console can be used to enforce policies (such as NAP and Smartcard), set IPs, etc.
UAG also provides access, from within the same cluster, for down level and non Windows clients

As its name suggests, Unified Access Gateway provides multiple access scenarios for managed remote clients (via UAG DirectAccess) as well as unmanaged, or even ‘foreign’ remote access clients in a secure way. By utilizing various remote access technologies, UAG can publish business server applications to unmanaged clients enforcing various authentication methods.

Read the complete article @> Microsoft Forefront Unified Access Gateway Product Team Blog : Introducing UAG DirectAccess solution

Posted at 8:18 AM by John Gilham | Category: Network Services | Permalink | Email this Post | Comments (0)

6/22/2009

Microsoft a Leader In Security

Talk about a turnaround. It's always hard to recognize the larger, slow-moving paradigm shifts as they happen. But after a decade of bad press regarding its commitment to software security, Microsoft seems to have turned the tide. Redmond is getting consistent security accolades these days, often from the very critics who used to call it out. Many of the world's most knowledgeable security experts are urging their favorite software vendors to follow in the footsteps of Microsoft.

<snip>

Notable Quotes (from here)

“Many of the world’s most knowledgeable security experts are urging their favorite software vendors to follow in the footsteps of Microsoft.”
"Microsoft becomes high priest of secure software development." – CNET
“As an industry we should recognize the sea change in Microsoft’s approach to security… and encourage other vendors to follow Microsoft’s lead." — SANS NewsBites
“In 2004 Microsoft was a couple years into its Trustworthy Computing Initiative but it remained the software company IT security practitioners hated with glee…. That’s not so much the case today." — Computerworld

Read the rest @> Pigs fly! Microsoft leads in security | Security Central - InfoWorld

Posted at 10:23 PM by John Gilham | Category: Security | Permalink | Email this Post | Comments (0)

Pros and Cons of Desktop Virtualization (VDI) – Tough to Generate Initial ROI

Successful server virtualization deployments lead many IT managers to believe desktop virtualization would provide the same benefits. While that is partly true, companies need to be aware of how the two technologies differ, industry experts caution.

"Desktop virtualization is a very different beast and should not be treated as simple enhancements to the server strategy," says Natalie Lambert, principal analyst at Forrester Research. "The drivers are entirely different and the environment will present new challenges to those experienced with server virtualization."
For instance, desktop virtualization doesn't offer the near-immediate cost benefits many cite with virtual server rollouts. And while virtual servers present new security and management challenges, many argue that in the desktop realm, virtualization improves security and manageability for IT departments. In addition, the sheer numbers involved can be strikingly different.
<snip>

Read the rest @> Weighing the pros/cons of desktop virtualization - Network World

Posted at 12:03 PM by John Gilham | Category: Virtualization | Permalink | Email this Post | Comments (0)

RSS Feed