If your like me and starting to play with the new Exchange 2010 Beta, you will be happy to know that the Exchange Team have made things a little simpler out of the box for installing the Server 2008 OS pre-requisites.

The XML files for ServerManagerCMD.exe are now included on the media at “.\Scripts\Exchange-<Role>.xml”. Each role has its own .xml to be loaded atop the “Exchange-Base.xml” file, or if your lazy like me you can use the “Exchange-All.xml” to load up everything you could need. Simply run the following command to get yourself on your way

servermanagercmd.exe –ip C:\EX2K10\Scripts\Exchange-all.xml

Note. The Exchange-All.xml file includes the Failover Clustering feature which is only available on Server 2008 Enterprise edition. If you are installing onto standard, you need to comment/remove the following line in Exchange-all.xml otherwise you will receive an error.

<Feature Id="Failover-Clustering"/>

Lots of juicy details about the Beta can be found over at the Exchange Teams blog post along with the a list of other pre-reqs you need at the new Exchange 2010 TechCenter.

Beta Release Announcement - http://msexchangeteam.com/archive/2009/04/14/451032.aspx
Exchange 2010 Beta 1 Pre-Reqs http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

I came across an interesting little issue with DPM 2007 the other day. A freshly installed server was refusing to fire off any scheduled backups after its initial replication. There were no errors in the DPM logs and no errors in the System or Application logs, it was just like they never existed.

After a little digging, I found out it wasn't DPM that was having issues, it was actually SQL. All of DPM's jobs and their scheduling is actually handled by the SQL Server Agent on the DB server responsible for your DPM database. This is why you must install sqlprep.msi from the DPM 2007 CD on your DB server, before you can install DPM 2007 onto your Backup server. It ensures all the binaries and scripts are present for the SQL Agent to do its job.

So now knowing its the SQL agent that fires off the jobs, I had a quick look into my SQL Agent logs. It was apparent pretty quickly that I was receiving an access denied error occurring every 15 minutes when my sync jobs should be occurring. I opened up one of the SQL Agent jobs, to find the following command.

"C:\Program Files\Microsoft Data Protection Manager\SQLPrep\TriggerJob.exe bba98fd4-da42-4036-bf01-755b1c1912f0 140af0e2-08fd-4e5a-bca4-7ce9a2e98264 server.domain.com"

A simple copy and paste into a command prompt, and the above command works like a treat, no errors, and after flicking back to DPM, a synchronisation is happening. Using RunAs, I open up another command shell as my SQL Agent service account and try again, this time "Access is Denied". Filemon quickly reveals the issue, my SQL Service Agent account doesn't have access to the DPM directories. These have been locked down to "Administrators" and "System".

As all of my SQL Service accounts only have user privileges, obviously this isn't going to work. After granting my SQL Agent service account "Read and Execute" access to the folders containg TriggerJob.exe, the backup jobs are now firing off every 15 minutes as expected and working like a charm.

Another little joy of running your service securely as unprivileged users. Hopefully this helps someone out there not throw DPM in the bin after 1 week, because it won't fire off any jobs for them :)

Russ

One of the great new features of Server 2008 is the ability to implement fine-grained password policies (FGPP) using password settings objects (PSO). In English, you can specify account lockout, password complexity and history requirements via group memberships or directly applied to a user. Note, this functionality is de-coupled from the Group Policy/Domain method that you currently deploy domain-wide password policies with however they still apply if no FGPP applies to a user account.

Being a new feature of 2008, you will require your domain to be at Server 2008 Domain functional level which effectively entails that all your DC's are running 2008. So if you still have 2003 DC's in your environment, you will need to upgrade before you can take advantage of PSO's.

Without getting too deep, the following should help you understand how it's pieced together.

1. The policies themselves are stored in the AD Domain partition at "CN=Password Settings Container,CN=System,DC=domain,DC=com"
2. Each PSO contains all the attributes that define your new FGPP
3. The msDS-PasswordSettingsPrecedence attribute specifies the weight of the policy. Used to determine the winning policy if multiple are applied.
4. The msDS-PSOAppliesTo attribute on each PSO object links it to Groups or Users.
5. The msDS-PSOApplied attribute on Groups and Users shows the PSO's that are currently linked.
6. msDS-PSOAppliesTo and msDS-PSOApplied are linked attributes. You require permission to the PSO to change this attribute.
7. The msDS-ResultantPSO attribute on Users only shows the winning PSO in the case the multiple objects are linked.
8. If a PSO is applied directly to a User, it will override any PSO inherited by group membership. If multiple are applied directly to a user, the one with the lowest AD GUID wins.

OK, that was a little deep, but you need to understand how this really plugs together. A couple of key points, you should only apply PSO's to group objects unless required for a specific user and Restrictive policies should generally have a greater weight.

So with that all behind us, here is some code to allow you to create your PSO's as required. Simply change the policy attributes to be what you want and save the script as a .ps1 file and execute. The code below will create a new PSO called "PSO-Administrators". It currently has the the default domain policy settings applied.

# Modify This section for your new policy
# Min/MaxPasswordAge in Days
# LockoutThreshold/Window in Minutes

$PolicyName = "PSO-Administrators"
$PolicyPrecedence = 10
$ReversibleEncryption = $False
$HistoryLength = 24
$ComplexityRequirements =  $True
$MinPasswordLength = 7
$MinPasswordAge = 0
$MaxPasswordAge = 42
$LockoutThreshold = 5
$LockoutWindow = 30
$LockoutDuration = 30

# Change the Time values to I8 values (KB954414)
$MinPasswordAge * -864000000000
$MaxPasswordAge * -864000000000
$LockoutWindow * -18000000000
$LockoutDuration * -18000000000

# Bind to the Domain of the logged in user and grab the Domains Distinguished Name
$Domain = [adsi]("LDAP://RootDSE")
$DomainNamingContext = $Domain.DomainNamingContext
$PSContainerDN = "CN=Password Settings Container,CN=System,$DomainNamingContext"

# Bind to the Password Settings Container and Create The Object
$PSContainer = [ADSI]"LDAP://$PSCDN"
$NewPSO = $PSContainer.Create("msDS-PasswordSettings","CN=$PolicyName")
$NewPSO.Put("msDS-PasswordSettingsPrecedence",$PolicyPrecedence)
$NewPSO.put("msDS-PasswordReversibleEncryptionEnabled",$ReversibleEncryption)
$NewPSO.put("msDS-PasswordHistoryLength",$HistoryLength)
$NewPSO.put("msDS-PasswordComplexityEnabled",$ComplexityRequirements)
$NewPSO.put("msDS-MinimumPasswordLength",$MinPasswordLength)
$NewPSO.put("msDS-MinimumPasswordAge",$MinPasswordAge)
$NewPSO.put("msDS-MaximumPasswordAge",$MaxPasswordAge)
$NewPSO.put("msDS-LockoutTreshold",$LockoutThreshold)
$NewPSO.put("msDS-LockoutObservationWindow",$LockoutWindow)
$NewPSO.put("msDS-LockoutDuration",$LockoutDuration)
$NewPSO.SetInfo()

All things going well, you should have a new PSO ready to be applied. As mentioned earlier, you use the msDS-PSOAppliesTo attribute to select the groups you wish the PSO to apply to. You can easily do this using "Active Directory Users and Computers" on a Server 2008 machine, enable "Advanced Features" under the view menu, and expand the "System\Password Settings Container"

Right-Click your new PSO and select properties. Scroll down to msDS-PSOAppliesTo and click Edit. Click "Add-Windows-Account" and add the Groups/Users as required.

Now when any users in those groups login, your new policy will be applied to them.

Hopefully this gives you a bit of a head start into playing with PSO's. If you want to learn even more, check out the following TechNet article http://technet.microsoft.com/en-us/library/cc770842.aspx

Russ

A fantastic new years present for those of us using NLB with ISA 2006. The ISA team have released a hotfix to enable Integrated NLB using Multicast. Up until this point, you could only use Unicast NLB with ISA integration which precluded admins from using virtual machines under Virtual Server 2005 R2 as part of an NLB farm when the VS is hosting servers that would utilise the ISA VIPs.

You can find all the details in the KB article below, not for those with weak stomachs, but ease of management Multicast NLB couple with the tight integration with ISA 2006 make this a must have update for any ISA 2006 NLB Farm.

KB: An update enables multicast operations for ISA Server integrated NLB

The guys over at the Sharepoint Team blog have given us all a little insight into the upcoming Service Pack for Sharepoint, Head on over and have a read. If your curretly hosting with Sharepoint, it's guaranteed to put a smile on your face. Some highlights for hosters include

• Windows Server 2008 / IIS 7 Suppport
• Rename Host-named site collections
• New People-Picker options (Scope selection to an OU)

You can grab Release Candidate 1 from connect if you have some spare time and super keen to check out whats new and happening.