If you are to learn proper scripting, you may as well invest the time to learn the Linux 'world-wide standard' scripting, not M$ copy/derivative of that arrangement... and then you won't have to worry about licences, or having enough of the right type, pre-purchased etc, to keep the network running.
Note that the earlier comment re lack of reverse-compatibility with M$ servers was also by me, and I had intended my name to be included (rather than anonymous),
Graeme (prof at-symbol post.harvard.edu)
Microsoft has about 90% of the world's computers under its control. So if it does something then that IS the standard. Just because Linux is open source doesn't mean it is the only thing in the world allowed to do something a certain way.
What's called a "standard" is not dependant of whatever market share. It's supposed to be established by an independent body where several (an any) manufacturers can participate in its conception, where research centers and universities can also bring forth the latest "application-ready" results, consolidating evolution and research in a given field: the later is NOT based upon marketing strategies and efficiency, but upon research and technological quality/efficiency. For all the later reasons, it's thus easy to understand why Microsoft's products and technologies cannot and will never be considered as "standards", more over when considering their patents: a standard CANNOT be owned by a clique, it has to be accessible to any company, university, etc. WITHOUT the side-effect of enriching a small clique who would own whatever so-called "standard" (else that standard would be driven by the greed of such a clique, not for "the better" of us all and of the domain of application itself -here it would be computing sciences-, which is a deviation from what should be a standard)! LOL it's so evident that It feels weird to recall that simple fact to the stupidity of the previous post...
Just to complete my previous post.... As an example, Microsoft would embrace and/or implement standards, they can also provide their own research to establish new standards (from then on freely offering sources codes and all to the community and market). Another example: XML is NOT a Microsoft guyzmo, even though MS has a big pie of the market is irrelevant.
Windows Server 2008 presents some compelling reasons to upgrade.
RRP: TBA
Having problems with complex data center? Simplify your data center now.
| Apple iPhone 3GS 32GB | 33 plans |  1% |
| Apple iPhone 3GS 16GB | 33 plans |  1% |
| Nokia N97 | 37 plans | 1% |
| Apple iPhone 8GB | 33 plans | 1% |
| Nokia E63 | 33 plans | 1% |
| Apple mobile phones | 1% |
| Nokia mobile phones | 1% |
| Sony Ericsson mobile phones | 2% |
| Samsung mobile phones | 1% |
| LG mobile phones | 1% |
Can not-so-smart meters help the NBN?
Can the Telco Reform Act be win-win?
Has New Zealand's smiling assassin delivered?
What makes you click?
Tell us for a chance to win a $1,000 GAME gift voucher.
Click here for more.
Win an iPhone 3GS!
Sign up as a ZDNet Australia member during November and you'll go in a draw to win an iPhone 3GS!
Click here to sign up!
Best Laptops
Check out the best laptops here!
Click here for more.
Be very careful of building applications based on M$ servers... Server 2003 dropped support for earlier API calls, and our application failed to work... The problem was that with M$ you can't really stay on older versions, as support is dropped etc, yet there is no corporate commitment to retain reverse compatibility. It would not have hurt M$ to retain the API support... but M$ just thought everyone should be migrated onto the newer M$ ways of doing things (.NET etc further lock-in). Our problem was that we were not yet ready to re-write that functionality.. and the programers who did write the earlier stuff were no longer around. To this day, for adding new users to an M$ Access application, we need to copy the database off the 2003 server back to the prior server (NT server) and make the changes, then re-copy the database files back onto the 2003 server. Clearly the application still works, but what changed was M$' support for functions done within their own complementary products (eg Access).
The good: Can't think of any... Presumably some of the security problems of the earlier product are addressed... but at a cost of greater lock-in.
The bad: Our experience with non-compatibility in 'upgrading' from one M$ product to its replacement has meant that we are seriously looking to standardise on only Linux servers, knowing that Linux retains strict reverse-computability and adherence to true standards.