If you were thinking about attending a PowerShell talk at LISA (Large Installation System Administration conference), the answer is NO. Someone suggested that the attendee’s of this conference would love a PowerShell talk so I submitted my Monad Manifesto as a draft with the thinking was that I would bring that paper up to date, provide more details etc. I’d be hard pressed to think of a topic more relevant to people managing large systems so I thought it would be a good fit. Sadly, the paper got turned down and the reject notice (below) provided feedback from various reviewers. I thought you might enjoy these as many of them are highly entertaining. I especially enjoyed this one: “tone of the paper is often promotional rather than discursive, at times frenetically so. This detracts from its readability and often results in emotional effusion in place of technical substance”. “Frenetic” – he had me on that one (though I was planning to do a “tone” pass on the final paper). I wasn’t quite as convinced by this one, “the author does not seem to understand the Windows system administration communities”. J Enjoy. Jeffrey Snover [MSFT] Windows Management Partner Architect Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx I am sorry to inform you that your paper: “Windows PowerShell: A New Approach to Automation” was not selected by the Refereed Paper Program Committee for the LISA 2007 conference. Please acknowledge receipt of this email to . We had 55 submissions and were only able to accept 22. I am enclosing some comments on your submission by members of the programme committee – I hope that you will find these helpful, and that you will consider submitting to LISA again in the future. I hope that you will be able to attend the conference in Dallas and I look forward to meeting you there – you may also like to consider submitting a poster or a WIPS presentation: http://www.usenix.org/events/lisa07/cfp/workshops.html. Many thanks for your submission Paul Anderson I want to accept this paper but after careful consideration I find that I can’t recommend that we do so. The author provides a great deal of information about the work, but in my opinion it is both the wrong information and there is not enough technical detail in the information provided. I find this disappointing because, as I said, I wanted to accept this paper. The most notable lack is what role the author played in the work. Did he write the programs himself? Was he a member of the team that wrote the programs and, if so, what was his role in the team? What is also lacking is any detail about how the programs were written, what problems were encountered while implementing the programs, what design decisions had to be revised because of these problems, etc.? Next, the author gives very few examples of how the work is used, nor does he include any information saying whether the programs have been used and where. Is this just a research effort? Are the programs being used to manage internal systems at the author’s institution? If they programs are being used, for how long and under what circumstances? What changes (if any) have been made or are planned based on feedback from actual users (system administrators, one presumes)? The author provides no conclusion. What did the author learn from writing these programs? Did the programs actually provide a better solution to the original problem or did they turn out to be less useful than hoped? If the latter, why? The author mentions providing references in the final paper but those references are needed in this submission in order to judge the work. Has anything like this been done before? If so, why did the author implement his solution? What about the original work didn’t suit the author’s requirements? How heavily did the the author base his work on previous work? If nothing similar has been done before (an unlikely proposition, in my opinion), what other related works did the author consider when implementing his solution? Did the author look to any previous works to find problems to be avoided and, if so, how did the author avoid those problems. Another small item that is missing is the availability of the work. Will it be given away? Provided under some sort of license? Sold? Integrated into another Microsoft product? Strictly speaking this isn’t required in a submission but it would have been nice to have. When all the missing bits are added up, this submission comes off as something much closer to a product whitepaper than a technical paper suitable for inclusion in a refereed journal. I find that disappointing because the problem the author set out to solve is indeed a significant one and the solution appears (on the surface, at least) to be both interesting and worthwhile. I *strongly* encourage the author to resubmit this paper again next year but with many, many more technical details. ======================================================================= This paper describes PowerShell, a command line administrative facility (“shell”) for the Window (.NET) environment. While this work is potentially useful, the present paper has many problems that prevent it from being acceptable. First of all, despite its length, there is relatively little specific information about what PowerShell actually does. The few example are very brief, simple (or even simplistic) and repetitious. From the information given, it is very hard to evalutate the work’s scope or technical quality. Secondly, the tone of the paper is often promotional rather than discursive, at times frenetically so. This detracts from its readability and often results in emotional effusion in place of technical substance. Thirdly, the paper makes no reference to the VAST amount of previous work and other similar solutions for Windows. Its enabling assumption, that the choices for Windows administration are GUIs or writing programs, is simply false, and it is something that has been false for almost a decade. The number of Microsoft-provided and third party command line utilities and scripting infrastructures is legion. Finally, the author does not seem to understand the Windows system administration communities. There are reasons most Windows tend to use VB for their scripting needs (as well as other automation solutions), many of which are cultural rather than technical. In addition, those Windows administrators coming from and/or involved in other OS environments also already have other solutions and do not really need PowerShell. ======================================================================= A very interesting paper providing an introduction to the powershell architecture and concepts. Whilst providing a good introduction to the subject as a general systems administrator I do feel the paper did not make it clear enough what the advantages of Powershell over a traditional vb/batch scripting solution were in a real world environment. It may be an idea to include a worked example directly comparing powershell with a batch/vbs solution highlighting the advantages of powershell over the traditional solution in an “in the field” environment. ======================================================================= As you acknowledge references and discussion of related work need to be added. 4.3 and 7 – management model discussion does not seem as directly relevant to addressing the core problem identified at the start of the paper, ie. the paper could lose it and not be any less strong. 5.1 – not being fully .Net aware the example here needs a lot more explanation for me, eg. “structure the automation in terms of nouns and verbs” and “using the CmdNoun and CmdVerb attributes” meant little to me. It was not clear from this how easy it would be to write a CmdLet to process, lets say, a web servers access/error log (normally basic test) instead for example. 6.2.1.3 and 6.3 – the discussion of the PowerShell language itself mentions but does not give any detail or examples of how CmdLets are actually written in this language 6.2.1.7 – could do with some elaboration and more explicit comparisons to justify the claims for improved security. 6.2.1.8 – the statement “Data can be output in graphical formats to leverage the PCs interaction and visualization capabilities” seems to be inconsistent with statement in 6.2.1.1 that “a CmdLet never directly communicates with the user” – I may just be misunderstanding the intent. Overall I found this a very interesting paper and the approach taken by PowerShell to implement a long overdue overhaul of Windows (and Unix) command line management with GUI integration is to be welcomed.