Thursday, April 19, 2012

PowerShell Script to Set Public Folder Replication Schedule Recursively in Exchange 2007

I've recently been tasked to replicate a lot of Exchange 2007 Public Folder data to another server.  I'll blog the steps here shortly, but first, I had to write a quick power-shell script to do it, as there were over 100 public folders in the root public folder, and they were all set to not replicate.

I had already used the MS script AddReplicaToPFrecursive.ps1, but it doesn't set the replication schedule if it wasn't set before.

This script will walk through all of your public folders and set the replication  schedule to "always"

It logs to C:\set_pf_log.txt and you can see two work files it also makes in C:\ - modify as you wish.

It's my first PowerShell script, so be gentle. :-) I don't know how to handle wrapping long folder names from the Get-PublicFolders command, so it won't process a long PF name.

# Set Public Folder Replication Schedules Recursively
# NOTE: If you have very long public folder names, they may wrap, and will not be handled correctly here.
# Define Varables

$filename_log = "C:\set_pf_log.txt"
$filename_pf_long = "C:\set_pf_long.txt"
$filename_pf_short = "C:\set_pf_short.txt"

# First, get a list of all the public folders and write them to $filename_pf_ong
write-host "Fetching Public Folders and writing to $filename_pf_long"
write-host "Fetching Public Folders and writing to $filename_pf_long" | out-file $filename_log -append

get-publicfolder "\" -recurse | fl identity > $filename_pf_long

# Now we need to trim the file, as it also outputs 'Identity : ' which we don't want

write-host "Trimming $filename_pf_long into $filename_pf_short"
write-host "Trimming $filename_pf_long into $filename_pf_short" | out-file $filename_log -append

get-content $filename_pf_long | foreach-object {$_ -replace 'Identity : ',''} > $filename_pf_short

# Now loop through the file, executing our action for each public folder
# NOTE - The action is commented out, using write-host to output to the console instead. If you want to make this actually run, remove the # in front of set-publicfolder

foreach($line in get-content $filename_pf_short)
    if ($line -ne "")   
        write-output "Processing $line"
        write-output "Processing $line" | out-file $filename_log -append
#         set-publicfolder $line -ReplicationSchedule Always

write-host "Complete!"

Wednesday, April 18, 2012

A Call to Revive the Uniform Driver Interface (UDI)

(UDI’s Home - )

Over the years, I have wished for some sort of universal driver, so that we didn’t need one driver for FreeBSD, one for Linux, one for Windows Xp, one for Windows 7, etc.  

I started searching the internet to see if anything was in development on such a framework, and was surprised to see that it did indeed exist, and was already pretty much dead before I even knew it existed.

The Uniform Driver Interface (UDI) was, created by a cooperation of some big industry players (Intel, SCO, Adaptec, Sun, IBM, DEC, Compaq/HP, etc).
However, I notice Microsoft wasn’t part of it, which is one of the reasons it is currently languishing. 

It’s specification was released in 2001 under a BSD-style license, so it’s very Open-Source. 

During my 'autopsy-research', I found some muttering about it being as complex and bloated as CORBA, but I can’t find any proof of that.  

I think the real damage to it was being blasted by Richard Stallman

I understand where Richard Stallman’s stance on UDI is coming from, but I do not agree. I’ll get into why shortly.

First, let me state this;

The _BEST_ think for Free Software would be UDI, because the largest thing holding back Free Software Operating Systems is drivers.


 - Try running quality accelerated X-Windows on FreeBSD, and a recent ATI card.
 - Try booting/using OpenIndiana on a cheap desktop quality board with a generic Marvell or other SATA controller and Network Card?
-  How’s your Intel GMA500 video working under Ubuntu?

This list is endless. Linux is in the best position for hardware drivers as it has the larger installed base, and so hardware vendors do have decent support. Solaris/(x)BSD’s seem to be next, and it quick drops off the face of a cliff after that. 

If you wanted to revive the interesting Plan-9 OS, or if you wanted to branch from an existing Free OS and make some large changes to the kernel/scheduler, or you wanted to try and design your own OS, you’re now going to need to write or port drivers.

This is a huge amount of time wasted on trivial matters that shouldn’t be. I believe in re-useable code, and not doing the same thing twice. We need to understand that skilled programmers are a resource like anything else, and we shouldn’t be squandering their time across repeating the same work for different OSes. 

Sure, it’s a rite of passage to code your own drivers – But when you have to code 27 drivers just to obtain basic functionality for your new OS, so you can work on what is really driving you to create that new OS, you’re wasting time.

Some Open-Source OS drivers come from the hardware vendor directly. A large percentage of the drivers in Open-Source OSes are reverse engineered.  While some are very stable, fast, and feature-rich, many are not. 

Why should the Free-OS crowd have to make do with lower quality drivers than those who run Windows?

Why should the programmers on the freebsd-scsi list have to deal with bug-stomping on reverse engineered drivers for a product that they didn’t make, when they could be working on the CAM structure (a product they are making)?

At the risk of over-simplifying Richard Stallman’s position, this is how I see his stance against it;

     There is a chance that a UDI driver made by/for an Open-Source OS team would be used in a commercial product and possibly distributed by the hardware vendor.

And you know what? Yup, there is a chance in the very early stages of a switch-over to UDI drivers that something like that may happen.  If you’re concerned, slap a GPL v3 license on the driver you code and be done with it.

However, no hardware manufacturer will ever take drivers from the Open-Source community and use them as their own for any considerable period of time– They will develop their own drivers, so they can properly support and control the quality and performance of their hardware. 

If the hardware vendors want to keep them proprietary, so be it. This is another key point (I think) in  Richard Stallman’s stance against UDI

-         If the big hardware vendors could release closed source UDI drivers, then the pressure on the hardware vendors to release open-source drivers would cease.

That’s very true, and possibly a concern. However, I look at this as a game of chess with big-picture goals, and short-term compromises.  

Yes, you may be taking a step backwards in the Open-Source drivers category, but you’d be _vaulting_ Open-Source OS’s miles ahead. 

Just imagine a copy of FreeBSD, Ubuntu Linux, OpenBSD, or OpenIndiana with the same driver support as Windows. 

As a user, think of what you could do with that system.

As a programmer, think of what you could concentrate on instead of tracing down bugs in reverse-engineered driver that so many people use with your software. 

You do realize that with technology like WINE, and Thinapp (which works under WINE nicely), a good Firefox cross-OS implementation, we're closer than ever to properly challenging Microsoft's dominance  on the PC market? If an Open-Source OS could run on anything that Windows runs on, what options would that give you?

UDI is something that the hardware vendors want (it’s why they all joined the working group). It’s something that any OS designer would want (less work for me? Great!), and it’s something that the end user will want (you mean all my hardware now works with FreeBSD?)

How do we get UDI started again? It’s a bit of a chicken-and-egg scenario:

1 - We need pressure on the Hardware Vendors to start releasing real UDI drivers for current hardware that people want. 

2- We  need pressure on the Open-Source OS developers to take the ProjectUDI sample implementations of UDI for their OS and integrate it into the recent releases of each OS.

With drivers available, and OSes to use said drivers, UDI will start gaining some ground.

If there are bloat or performance problems with UDI, they will be exposed, and worked around or repaired. Are there other hurdles to UDI acceptance? Lets expose and conquer them.

I’m very interested in any comments or suggestions about UDI, how it died, and anything we can do to get this project started again.