On server 2008r2 you can do import-module servermanager & then add-windowsfeature to configure features etc.. from PowerShell, this doesn’t exist out of the box on 7, however if you install this: http://code.msdn.microsoft.com/PSClientManager you have an equivalent set of modules

Handy eh!

Rob

As part of a larger project I’ve been involved with which uses an IIS7 web application (I’ve been helping the client with their infrastructure and integrating the application with AD) we hit an issue where some 3rd party pieces of code were using absolute links *tut tut*! rather than relative ones, this had the side effect that a user would start off their session using an SSL secured https session & after performing certain tasks would find themselves on http.  Not ideal!  The application also has a requirement that the web servers are able to connect to themselves on port 80 – this could not be changed & interfering with this connection would break functionality.

To resolve this I’ve implemented the Microsoft URL Rewrite module 2 for IIS7, with the following configuration:

1. Download and install the IIS URL re-writing module: http://www.iis.net/download/urlrewrite
2. Go to the site in IIS manager & navigate to URL Rewrite in the right hand pain
3. Create a new inbound rule with the following settings:
4. Match URL:
1. Requested URL: ‘Matches the pattern’
2. Using: ‘Regular Expressions’
3. Pattern: ‘(.*)’
4. Ignore Case: ‘True’
5. Conditions:
1. Input ‘{HTTPS}’ Type ‘Matches the pattern’ Pattern ‘^OFF$’
2. Input ‘{LOCAL_ADDR}’ Type ‘Does not match the pattern’ Pattern ‘127.0.0.1’
6. Action: ‘Redirect’ Redirect URL: ‘https://{HTTP_HOST}/{R:1}’ Append Query String: True Redirect type: ‘See Other (303)’

This will not only correct broken URLs which get returned but will redirect users who hit the site via http to https which is a requirement for the service.

Handy fix – I’d often use TMG / ISA to resolve this but this customer’s solution does not feature those products (the site is being deployed internally).

Rob

As part of a recent engagement I was asked to implement a solution to automatically export & archive System and Security logs from servers to a central location, the requirements were:

• Nightly time stamped archive of Security and System event logs to a central location
• Clear the local log once the archive has been successfully taken

I put together the following PowerShell script to achieve the above:

$locallocation = "c:logs"
$remotelocation = "\fileserverEventLogs"
$localmachine = $env:computername

$evtlgs = Get-WMIObject -Class Win32_NTEventLogFile -Computer $localmachine
foreach ($log in $evtlgs)
    {
    if ($log.LogFileName -eq "System" -or $log.LogFileName -eq "Security")
        {
        $timestamp = get-date -f yyyyMMddHHmmss
        $path = $log.LogFileName + $timestamp
        $store = $locallocation+$path+".evt"
        $backup = ($log.backupeventlog($store)).ReturnValue
        if($backup -eq 0)
            {
            $log.ClearEventLog() | out-null
            }     
        move-item $locallocation* $remotelocation$localmachine
        }
    }

The above script is executed by a Scheduled Task (which on another note are brilliant on Server 2008), the lines you’re interested in are the top 2 lines which configure a local location to write the log out to and the remote location to move the log to once it has been written.  I ran this script using a service account which has permission to write to the local and remote locations. 

If you wanted a different selection of logs to be archived you would adjust the

if ($log.LogFileName -eq "System" -or $log.LogFileName -eq "Security")

line to suit your requirements.

In our requirement the logs had to be archived daily, this was simply achieved by configuring task scheduler to run once per day at the desired time, no code changes are required. 

The requirement for only clearing the local log if the export was successful is met by checking the exit code form the backup, if this wasn’t 0 then the log wont be cleared.

I recently hit a problem with CWA being published behind TMG, CWA was accessible internally from a terminal server but would throw the above error when login was attempted via TMG’s reverse proxy. 

The solution (for me – there is a fair bit written about this involving SPNs which were not the issue in this case), was to enable anonymous authentication on the AuthMainCommandHandler.ashx file (within the /cwa directory) within IIS & all is well again, it is reported that this issue only occurs on Server 2008 & is an issue with the site creation wizard.

My colleague Simon also hit this issue publishing CWA behind UAG, so worth checking.

SharePoint is not my usual topic of conversation I will admit, however this caused me pain & isn’t documented from what I could find.

For what ever reason my local SharePoint workspace recently broke, giving me this error when I tried to launch it:

I tried the various recover my account links etc.. all to no avail, I came to the conclusion that I needed to re-import the backup of my workspace, however to do this I needed to delete the broken on my laptop, I couldn’t do this as I couldn’t log in to the workspace… 

So after some digging around I found the following location (this is on Windows 7, if you’re on something older, upgrade!):

C:Users<username>AppDataLocalMicrosoftOfficeGrooveUserAccounts

Under here are some folders with seemingly random names, deleting the folders essentially reset SharePoint Workspace to it’s defaults & allowed me to re-import my backup – note I only had one account configured, if you have more than one you’ll need to find a way to identify which is the one for your broken account – measure twice, cut once!  Doing this will obliterate your account & any data stored locally which means anything not uploaded yet will be lost – this wasn’t an issue for me but be aware of it before you delete the account folder, if it is an issue for you this solution probably isn’t suitable.

Server 2008 AD schema onwards has a very cool feature called fine-grained password policies, these can be a bit arduous to setup, the easiest way that I’ve found to set them up is to create an ldifde answer file and import them using that.  In this example I’m creating a password policy called ServiceAccounts and applying it to the group called ServiceAccounts. 

dn: CN=ServiceAccounts, CN=Password Settings Container,CN=System,DC=robsdesk,DC=com
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge:-1728000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:0
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:5
msDS-PasswordSettingsPrecedence:20
msDS-PSOAppliesTo:CN=ServiceAccounts,OU=DomainManagement,DC=robsdesk,DC=com

Execute this command:

Ldifde -i -f pso.ldf

This will create a policy with the following attributes:

• Maximum password age of 2 days
• Minimum password age of 1 day
• Minimum password length of 8 characters
• Password history
• Require complexity
• Store with reversible encryption
• 30 minute lockout observation window
• 30 minute lockout
• Lockout after 5 failures
• Precedence of 20 – like MX records the lowest ‘cost’ comes first.

Make accounts you want to apply the policy to a member of the group.  You can edit the settings in the policy using ADSIEdit by navigating to the Password Settings Container within the System container. 

More detail can be found here: http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx

Cheers,

Rob

Quick post and run but worth bearing in mind, if you’re doing FBA on TMG & are offloading SSL before the TMG box there’s a reasonable chance that you may not have any certificates installed on your TMG server.  If this is the case users will not be able to change their passwords & those with password must be changed at next login will not be able to log in. 

This is because the TMG server needs to be able to open an LDAPS connection to a DC to do the password change, the S in LDAPS stands for secure, no certificate = not secure.  Install certs, reboot & all is well in the world again.

I’ve recently been engaged on a project where we have multiple web servers (IIS7.5 on 2008r2 for those interested) which require exactly the same content and configuration (they’re sitting behind a Forefront TMG server using a web farm).  The configuration in IIS for this application happens to be complicated & while I have documented how to configure the servers, doing it over and over will not only be tedious but probably introduce some human error. 

To resolve this issue I implemented IIS 7’s shared configuration and put a process in to replicate the content between web servers.

You will need a domain account (or local account on each web server if your web servers aren’t domain joined) which will be used to access the shared configuration (it only does this – your web applications continue to run under what ever application pool identity you have set) and a file share to store the configuration on.

Assuming you’re at the stage of having a configured web server with the IIS configuration how you want it you need to export the configuration:

1. On the first web server / machine which will host the shared configuration create a directory & share it giving full share and ntfs permissions to the service account created, all other permissions should be removed.
2. In IIS manager on the server with IIS configured as per the previous steps click on the server node in the left pane, then open shared configuration in the right pane, then finally select the export configuration option on the right, store the export in the directory created in step 1, entering an encryption key (this should be recorded as it is needed for all nodes which will be accessing the shared configuration).
3. When exported tick the ‘Enable shared configuration’ box, enter the UNC path to the configuration (eg \machinenameiisconfig) enter the username domainserviceaccount and the password for that account, press apply, you will be prompted for the encryption key provided in step 2.
4. Restart the server to apply configuration, then check IIS is still functioning and the IIS manager can be accessed.

The above steps will reconfigured your already configured web server to work from the shared configuration, now we need to replicate the web content and configure all other web servers to work from the same configuration.

There are several ways of replicating the physical content, DFSR is one option, however I chose not to use it as the content on the web servers is staying static so frequent updates to the other nodes will not be required and it gives the operator responsible for the servers more control over how content updates are deployed.  So instead I used robocopy (which has been built in since Vista / Server 2008) to mirror the content from the configured server to all others (this was executed on the web server to be copied to):

robocopy \configuredwebserverc$inetpubwwwroot c:inetpubwwwroot /MIR

Once the file content was in place two quick steps are required to configure IIS to use the shared configuration:

1. Open IIS manager, click on the server name in the left pane, then select the shared configuration option in the right pane, tick the ‘Enable shared configuration’ box, enter the UNC path to the configuration as specified on the first web server (eg \machinenameiisconfig) enter the username domainserviceaccount and the password for that account, press apply, you will be prompted for the encryption key.
2. Restart the server to apply configuration, then check IIS is still functioning and the IIS manager can be accessed.

This process will replicate all application pools and IIS configuration, however if you have ODBC data sources etc.. (things external to IIS which your web applications are using) then you will need to find a way to replicate these settings as well. 

An important point is how IIS behaves if the configuration becomes unavailable, under Server 2008 (not R2) if the configuration disappears IIS will essentially stop, under R2 the server will detect this, continue working and reconnect when the configuration source comes back online.  You can enable offline files for added resiliency should you require it.

Two of the many significant changes coming with Exchange 2010 are the change to DAG’s and to terminate MAPI connections at the Client Access Layer. 

Under Exchange 2007 an Outlook user has the server name configured to that of the mailbox (server / cluster) name, under Exchange 2010 with the concept of DAG’s you no longer connect to the exchange mailbox server directly, your server name is one of your Client Access Servers.  In its out of the box configuration its not very fault tolerant, if the client access server is unavailable the client wont be able to connect.  Client Access Arrays along with load balancing (can be NLB, Forefront TMG or another solution) are the way to tackle this issue.

In this example I have a Forefront TMG (beta 3 – I’ve not upgraded to the RC yet…) server exposed to the internet, behind this I have two Exchange 2010 servers both running Hub, Client Access and Mailbox roles.  There is also a supporting AD, DNS, Certificate infrastructure etc… however I’ve not shown it in the interests of keeping this simple, thanks to Visio it looks like this:

I am publishing the following external names:

autodiscover.contoso.com – Exchange autodiscover

mail.contoso.com – OWA, OA, EWS, ECP, EAS

As we want to load balance / provide fault tolerance for our Exchange 2010 services we have a web farm created with Exch2010.contoso.com & Exch2010-2.contoso.com using HTTP / HTTPS GET requests to verify connectivity. 

Three publishing rules have been configured as follows:

All publish to the web farm containing the two Exchange servers.  Again in the interests of keeping this simple I’ve not gone into SSL offload & authentication delegation – best practice would have multiple listeners – FBA for OWA, NTLM for OA etc… but I’ve got one public IP so one listener it is!

To configure a client access array the following steps need completing (I’ve not documented the usual steps you would go through to configure your internal and external URL’s – you set these up as usual):

• Create a client access array

Creating the client access array is simple, all that is needed is to specify an FQDN (an internal name which doesn’t resolve on the internet is fine – the name doesn’t get registered in DNS) and name, in this case I used cas.contoso.com (original eh!) and the AD site the array will serve:

New-ClientAccessArray cas.contoso.com -FQDN cas.contoso.com -Site Default-First-Name-Site

This will create your new array & place all Exchange servers with the client access role in the site specified into your array.

• Configure mailbox databases to use the client access array – this information is then passed back to the client via autodiscover.

When the mailbox database has the RPCClientAccessServer field completed this specifies either a client access server or client access server array to be returned to the client through autodiscover. 

Simple enough to do, this is the command I used:

Set-MailboxDatabase testdb -RpcClientAccessServer cas.contoso.com

Once this has been set, allow a few minutes for replication & client connections will start to be directed to cas.contoso.com from autodiscover & existing clients will begin to update their configuration – the Exchange Server field in outlook will become cas.contoso.com.

So should one of your client access servers go offline TMG will send the connection to another server in the farm and the client will continue to work as it has as CAS array name specified rather than an individual server.

There is documentation on technet about this, however it’s still quite vague – as you would expect at this stage, more will come in due course.

Exchange… awesome product! 

Just found this gem of information on Anderson Patricio’s blog, something which stumped me when setting up some 2010 HA demo’s. 

Exchange 2010 allows you to create a highly available implementation with just two servers (excluding edge), you can combine mailbox, hub and client access on one box, do this twice & use a DAG to replicate the databases & you have highly available Exchange (you can use Forefront TMG to load balance). 

The Exchange 2010 DAG functionality replaces the CCR / SCR technology in Exchange 2007, like CCR DAG requires a file share witness to prevent split brain syndrome.  Typically in Exchange 2007 you would place this on a Hub transport server (having manually created the share & permissions), Exchange 2010 has a wizard to create the FSW on a remote server for you which is handy, however as I found out when I tried to use it against a non Exchange server it didn’t work, I manually created the FSW – putting it down to a Beta / RC bug, however it would appear that you need to add the Exchange Trusted Subsystem group to the local administrators group on the target server to allow the FSW wizard to work.

Rob