Configure Multi-path Input Output (MPIO)

Since NIC teaming is not supported in Windows Failover Clustering, MPIO must be used to create fault-tolerant network paths to the iSCSI targets.

Here's how the NICs are configured:

Data1 - Broadcom NICs are teamed using 10.1.1.20 and 10.1.2.20

Host1 - Broadcom #1: 10.1.1.10 /24
- Broadcom #2: 10.1.2.10 /24

Host2 - Broadcom #1: 10.1.1.12 /24
- Broadcom #2: 10.1.2.12 /24

Prior to configuration the MPIO optional component must be installed on the Host servers.

On each host, open iSCSI Initiator:
Click the Discovery tab.
Click Add Portal, type 10.1.1.20 and click OK.
Click Add Portal, type 10.1.2.20 and click OK.
Click Targets tab.
Click Refresh.
For each target, follow steps 7 through 17.
Click Target and then click Logon.
Click the checkbox for Automatically restore connection and also for Enable multi-path
Click the Advanced button.
Change Local Adapter from Default to Microsoft iSCSI Initiator.
Change Source IP to the IP address on the 10.1.1.0 /24 network.
Change Target Portal to 10.1.2.20 /3260.
Click OK.
Click OK.
Click the Logon button again.
Click the checkbox for Automatically restore connection and also for Enable multi-path.
Click OK (Note: this uses the default setting for the drop down menus on the Advanced screen).
Click OK
Now configure which MPIO mode to use.
Open Disk Management.
Right-click Disk X (X is whatever the new iSCSI target is) and select Properties.
Click the MPIO tab.
Change Load Balance Policy to Round Robin.
http://kb.open-e.com/entry/57/

How to Recover Exchange 2007 DB Mount Failure After Lossy Failover Occured

What can happen if log files are deleted or a failure happens during a clustered Exchange failover is a database mount failure (see screenshot).

Additionally, an examination of the state of the database also shows that the database is in a dirty shutdown state. To view the state open Exchange Management Shell on one of the affected Exchange servers. Run the ESEUTIL utility to view the current database state.

eseutil /mh "PathToDatabaseFile.edb"

In the results, you may need to scroll up, find the State (see screenshot). It will indicate that the database is in a Dirty Shutdown state. This means that the database was dismounted without allowing it to commit all log files.

To fix this, use the eseutil command to do a recovery. First, view the log files for the database to determine what the first three characters are. In my example, the first three are E02. If you database is in the First Storage Group, yours will probably be E00. Run the database Recovery.

eseutil /r E02

See screenshot for results.

Now, run eseutil /mh "PathToDatabase.edb" to see if you are still in a Dirty Shutdown state.

If the state is still Dirty Shutdown, also run a repair on the database.

eseutil /p "PathToDatabase.edb"

You will get a pop up asking if you want to proceed, click OK.

When this has completed, run eseutil /mh "PathToDatabase.edb" again to check the state. It should be in a Clean Shutdown state.

Repeat all recovery and repairs on all instances of the database on all nodes in the Exchange cluster.

Now open Exchange Management Console. Select the storage group that contains the database and click Restore Storage Group Copy. In the pop up, select Next, then Restore, then Finish.

Right-click database and select Mount.

After it mounts, click the storage group and then click Suspend Storage Group Copy and then Resume Storage Group Copy.

Network Access Protection (NAP) Components

My primary reference for the following content is the Microsoft MC TS Exam 70-642 Self-Paced Training Kit.

Network Access Protection (NAP) is a great way to assure that your network is secure and to allow "unhealthy" workstations a way to automatically make themselves "healthy".


In short, NAP allows you to evaluate the health status of a client and then decide what access to your network it will be allowed.


NAP Concepts


Enforcement Types

1. IPSec Connection Security
   
   Enforcing IPSec Connection Security requires a client to go through a NAP health check before they receive a health certificate. The health certificate is required before the client can connect to an IPSec protected host. This can be done by IP address or by TCP/UDP port basis.
   
2. 802.1X Access Points
   
   This method requires the use of switches or wireless access points that support 802.1X authentication. As with IPSec, compliant computers are allowed access to the network and noncompliant are allowed access only to remediation servers. When a computer is no longer in compliance, the switch or access point can also change that connections access settings so that you are assured that connections to your network are "healthy".
   
   There are two ways to control the level of access workstations receive:
   -Access Control List (ACL) -When a computer authenticates, if it's "healthy" you allow it to connect to your network without and ACL. If "unhealthy", then you apply an ACL that limits what the computer can do.
   
   -Virtual Local Area Network (VLAN) - VLANs are setup so that "healthy" computers are put on separate VLAN identifiers than "unhealthy". This prevents workstations on each VLAN from communicating with each other without a router.



3. VPN Server

VPN server must be running Windows Server 2008 Routing and Remote Access. As with other methods, computers have filters applied or not applied based on their health status.


4. DHCP Server
   
   Requires the use of DHCP server. Allows you to provide different sets of DHCP settings based on the health status. When the health status changes, the client will renew DHCP settings and therefore be given the appropriate settings based on the current status as it changes. Only drawback is that this can be easily bypassed with a client that manually sets their IP configuration.

Agents, Validators, and Network Policy Servers

1. System Health Agent (SHA)
   
   Windows Vista, Windows Server 2008, and Windows XP with Service Pack 3 include a SHA that will monitor the Windows Security Center settings. Admins create policies that evaluate these settings and control access based on the Statement of Health (SoH).
   
2. System Health Validator (SHV)
   
   This component resides on the Network Policy Server (NPS) and creates a Statement of Health Response (SoHR) that determines the level of access a client should have and whether or not remediation is needed. The SHV on Server 2008 communicates with the SHAs on Vista and XP w/ SP3.
   
3. Network Policy Server (NPS)
   
   Installing NPS on Windows Server 2008 acts as a RADIUS server evaluating the health of client computers. Deploying two NPS servers is recommended since clients are required to communicate with the NPS server to maintain access to the network.

...Next Post, Step by Step setup of NAP

IMAP Authentication Problems

Every day you learn something new when you work in IT...

We recently upgraded our phone system to provide Unified Messaging services to our users. To do that, we had to enable IMAP connections between the Unified Messaging server and our Exchange 2003 server. For the first group of users, we were able to get this working and everything looked great.

However; in my second group of users, I found there were two that the IMAP connection between the two servers would not authenticate.

Having very little experience troubleshooting IMAP I was puzzled. I checked the user's account properties and verified that the correct username was being used and verified with the user the correct password. IMAP was also enabled on the user account.

Testing through a Telnet session showed us that there something wrong with the username or the password as attempting to connect gave us a failure with message "bad username or password".

Then, for some unknown reason, I decided to try using the User Principal Name (UPN) instead of the SAM username which was working for all the other users. Like the sun coming through the clouds on a rainy day, the login was successful! I found that using the UPN allowed the non-working users to logon and also worked for user's that were configured using the SAM username.

I did some more investigating and figured out why.

There are a few ways to authenticate when using IMAP

1. SAM style username
   
   SAM accounts were used in the days of Windows NT and are still used for local workstation users. In Active Directory 2000 and newer, user account information is stored in the NTDS.dit file. For backwards compatability, it is still possible to use the SAM style username to logon to IMAP.
   
   When using the SAM style username, Active Directory will evaluate the username you submit and the Alias of the user account. This may not be intuitively where a Windows admin will look since controlling the username associated with a user account is modified on the Account tab in the User logon name field.
   
   When both the User logon name and Alias values are the same, it can seem like IMAP authentication is using the User logon name from the Accounts tab. When the two values are different, you will eventually figure out that IMAP authentication is using the Alias field found on the Exchange General tab.
   
2. Domain name + Alias
   
   The IMAP username can also be in the form of DOMAINNAME/ALIAS when a user has just one mailbox or DOMAINNAME/ALIAS/MAILBOX if a user has more than one mailbox.
   
   Like using the SAM style username, you could have a user with a different username for logon, an alias for IMAP, and then the added confusion of possibly needing to specify a specific mailbox.
   
3. User Principal Name
   
   Definitely what I would consider the preferred method. Using this method is a little straightforward as it should be more universal to all of your users and does not rely on them to have knowledge above and beyond their email address (at least for most environments).
   
   The User Principal Name is simply the User logon name and the UPN suffix. The UPN for my sample screenshot would be tester@testlab.domain. As you can see, the Alias TesterMailbox, is different from the User logon name.

http://msexchangeteam.com/archive/2004/03/31/105275.aspx

Certificate Authority Setup Windows Server 2008

I've been working on my test setup for PKI in my lab.

What I want to do is start with a stand alone Root CA on a Workgroup Windows Server 2008 server.

Then I want to install an Enterprise Subordinate CA on a domain member with Windows Server 2008 Enterprise edition.

Conceptually this is a fairly straight-forward design and common practice. Some organization may require more tiers for security purposes but essentially they setup a stand alone root CA that can be taken offline to remove risk of being compromised.

I found several sources of documentation to do this in MCITP training books and on Microsoft Technet. Unfortunately none of them were complete. They each left out a couple steps that prevented me from successfully getting the subordinate CA service started.

Here are all the steps to create a two-tier CA hierarchy with a stand alone Root CA and Enterprise Subordinate CA.

1. We'll start with a server we'll call RootCA. The server should have Windows Server 2008 Standard, Enterprise, or Datacenter installed.
2. Open Server Manager, click Roles, click Add Roles and add the Active Directory Certificate Services Role.
3. The wizard is fairly straight-forward but I would recommend a couple changes:
   a) specify a root cert lifetime of either 10, 15, or 20 years.
   b)specify an encryption scheme of sha256, or sha512.
4. You now need to import the root certificate from RootCA into 2 certificate authority lists on SubCAa)Trusted Root Certificate Authoritiesb)Intermediate Root Certificate Authorities
5. Do this by getting on RootCA, click Start, Run, mmc and press Enter.
6. Add the Certificates snapin to the console viewing computer certs.
7. Expand Personal and Certificates.
8. Right-click the root cert and select Export and save the cert to a flash drive.
9. Put the flash drive in SubCA.
10. In Certificates snapin, right-click Trusted Root Certificate Authorities and select Import.
11. Select the root cert on your flash drive.
12. Also, right-click Intermediate Root Certificate Authorities and select Import.
13. Select the root cert on you flash drive.
14. After the wizard completes logon to the server that will hold the Enterprise Subordinate CA role. We'll call it SubCA.
15. Open Server Manager, click Roles, click Add Roles and add the Active Directory Certificate Services Role.
16. Some key parts of this wizard:
    a)Make sure you select the option that allows you to create an Enterprise CA
    b)Make sure you select the option that allows you to create a Subordinate CA
    c)When you get the screen that allows you to request the Subordinate CA cert, you must select the option to save the request to a file.
17. Now save the .req file to the flash drive and plug the drive into RootCA.
18. Expand Roles->Active Directory Certificate Services->right-click RootCA and select All Tasks-> Submit New Request.
19. Select the .req file from the flash drive.
20. Click Pending Requests.
21. Right-click the pending Subordinate CA request and select Issue.
22. Click Issued Certificates.
23. Double-click the issued Subordinate CA-> click the Details tab-> and click the Save to File button.
24. Click Next and then click option for PKCS #7 and select checkbox "Include all certificates in chain if possible".
25. Save on the flash drive.
26. Put flash drive in SubCA.
27. In Server Manager, expand Roles, Active Directory Certificate Services, and right-click SubCA and select Install CA certificate.
28. Select the certificate on the flash drive.
29. Right click SubCA and select Start Service.
30. If there are no other Subordinate CAs to add, the RootCA can be shutdown.
31. It's recommended to export and save the certificate to a CD and the store that CD in a locked safe.
32. The RootCA, if a virtual machine, could also be burned to DVD and also stored in the safe.

Windows Server 2008 Password Security Objects: Granular User and Group Password Security

A new feature in Windows Server 2008 allows administrators to create PSOs (Password Security Objects) for much more granular password security settings.

Until now, a domain administrator could have a setup of password security settings set at the domain level that applied to an entire domain.

That option is still available and admins can now create PSOs that can be applied to a user or group object. The PSO has all same settings available that you would normally set using your Group Policy Object Editor such as Account Lockout Duration, Password Complexity Requirements, Password History, Password Length, etc.

In addition to those settings, there is also a setting called msDS-PasswordSettingsPrecedence. It's used to control which policy should be used should an object inherit more than one PSO. For example, if a user, Bob Smith, is a member of the group Sales, and has a PSO called SalesPSO connected to the Sales group and and PSO called AllUsersPSO connected to the Domain Users group object, the msDS-PasswordSettingsPrecedence settings from each of the PSOs will determine which PSO is applied. The winner will be the PSO with the lower number.

If AllUserPSO has a value of 50 and SalesPSO has a value of 25, the settings from SalesPSO will be applied and ONLY those settings.

***PSO settings are NOT cummulative.***

You may be wondering what happens when PSOs are attached to both the groups a user is a member of and to the user object itself.

First of all, if one or more PSOs are connected to a user object, NONE of the PSOs applied to group objects are applied.

Then, as before, the PSO (applied to the group object) with the lowest value is the winner.

So how do I create PSOs? PSOs are created using ADSIEdit.

1. Go to Start -> Run, type mmc, and press Enter.
   
2. Click File -> Add/Remove Snap-in and add ADSIEdit.
   
3. Right-click domain name, select Connect To, Type your domain name in the Name field and click OK.
   
4. Now expand/drill down by double-clicking DC=YOURDOMAIN,DC=COM then CN=System, then CN=Password Settings Container.
   
5. Right-click in any free space on the right-hand side and select New->Object.
   
6. The msDS-PasswordSettings class will be highlighted. Click Next.
   
7. As you click Next, the wizard will guide you through all the basic settings of a PSO. Remember the msDS-PasswordSettingsPrecedence will determine which policy is applied.
   
8. Settings that involve times such as msDS-MaximumPasswordAge, can be set with the format Days:Hours:Minutes:Seconds or d:hh:mm:ss. So if you want passwords to be good for no more than 25 days, you would type 25:00:00:00.
   
9. Finally, you'll get to a screen where you can click Finish. At this point, the object is created and can be managed from the Active Directory Users and Computers MMC Snap-in.
   
10. From ADUC, click View->Advanced Features.
    
11. Open the System container and then also the Password Settings Container container.
    
12. Right-click the PSO object and select Properties. Click the Attribute Editor tab.
    
13. Locate the setting called msDS-PSOAppliesTo. Edit the setting with the location of the object you want to apply the policy to by clicking Edit and then click Add Windows Account. Add groups and/or users that the PSO should apply to. For my example, I've applied the PSO to a group called G_GranularPasswordSecurity. Click OK.
    
14. The msDS-PSOAppliesTo attribute will now have the user and/or group object SIDs added.
    
15. Open the properties of any user that is a member of a group the PSO is applied to or that was listed in that you added in the last two steps.
    
16. Click the Attribute Editor tab.
    
17. Click Filter and select Constructed. This displays values that are not set directly on the object but are calculated based on PSOs linked to the user object at run time.


18. Locate the attribute called msDS-ResultantPSO. The attribute's value will be similar to CN=GeneralUserPSO,CN=Password Settings Container, DC=YOURDOMAINNAME, DC=COM.
    
    
    

Windows 7

The successor to Vista is due to come out sometime between Q3 2009 and Q2 2010.

I spent a little time installing and doing a brief evaluation of a Beta version.

For the most part, everything looks like Vista with a little more graphical tweaking.

One thing I'm very happy with, is the simplification of Windows Explorer. In Vista, Windows Explorer was often annoying with all the arrows you had to click to expand your view of the system drives. It made the interface very click happy.

In this Win7, or at least the Beta, Windows Explorer is much cleaner. They've gone back to more of the original style where you control the view with little expaner buttons. There aren't any more arrows you have to click to view or hide lists to get where you want.

I've also noticed a new category called Libraries. If you check out the screenshot, you can see that the libraries are Documents, Music, Pictures, and Videos. Shortcuts to these folders is nothing new but the concept of libraries seems appropriate.

Windows 7 also has changed the task bar at the bottom of the screen. In Vista, the task bar didn't look a lot different than previous versions. In Win7, the taskbar has been modified and reminds me somewhat of some Linux interfaces. For example, when you open Internet Explorer from the Quick launch bar, you don't see additional taskbar items when a Quick launch application is opened. This may take some getting used to but it seems to keep the screen a little cleaner, and little more clear of clutter.

Overall, at first glance, I'm impressed with some of the improvements that have been made. True, they aren't adding any drastically new features but it seems they're taking more steps towards making Windows more streamlined. One feature that I didn't see readilly available was integrated virtualization support. Not sure if this is still in the works or just not included in a Beta relase but integrated virtualization is supposed to also be included.