WMI to use or not to use
in [Visual Basic]
|
Prev: MSDN((VB6) won't install
Next: DLL Wrapper (I Think?)
From: Tom Shelton on 2 Jan 2010 13:31 On 2010-01-02, Tom Shelton <tom_shelton(a)comcastXXXXXXX.net> wrote: > On 2010-01-02, mayayana <mayaXXyana(a)rcXXn.com> wrote: >>> >>> I't works well for automating IIS. Creation of websites, etc. >>> >> >> Creation of websites? I don't pay much attention >> to the in and outs of Windows as a server, so I guess >> I wouldn't have come across that. But I still don't >> find anything in the CHM file, other than a brief mention >> that WMI can be used from as ASP page. I also don't >> find IIS in the index of my only WMI book. (Though that >> book is not much good, anyway. It's mostly a recipe >> book of pre-written scripts specifically for admins.) >> >> I don't understand where WMI comes into "creation >> of websites" on a Windows server. The functionality I've >> seen is aimed at administration of PCs/workstations. >> Do you mean like database access or server-side includes? >> Isn't that all in ASP? > > http://msdn.microsoft.com/en-us/library/ms525309.aspx > > Starting with IIS6 MS introduced WMI interfaces to configuring IIS. So, for > instance, I have an automated deployment tool that pushes a code package to a > server, then reads an xml configuration file and configures the IIS6 Metabase > accordingly. This way the site can be pushed to mutliple servers and setup > without having to log on to each one and configure IIS manually. > > By the way - yes, I wrote the tool. -- Tom Shelton
From: mayayana on 2 Jan 2010 15:07 > Starting with IIS6 MS introduced WMI interfaces to configuring IIS. So, for > instance, I have an automated deployment tool that pushes a code package to a > server, then reads an xml configuration file and configures the IIS6 Metabase > accordingly. This way the site can be pushed to mutliple servers and setup > without having to log on to each one and configure IIS manually. > That sounds like it comes under network admin. to me, but I actually don't know enough about running servers to understand exactly what you're talking about or how useful it is. (Or why you'd need to copy the same site/configuration to multiple servers, for that matter. You lost me on that one.)
From: Tom Shelton on 2 Jan 2010 15:24 On 2010-01-02, mayayana <mayaXXyana(a)rcXXn.com> wrote: > >> Starting with IIS6 MS introduced WMI interfaces to configuring IIS. So, > for >> instance, I have an automated deployment tool that pushes a code package > to a >> server, then reads an xml configuration file and configures the IIS6 > Metabase >> accordingly. This way the site can be pushed to mutliple servers and > setup >> without having to log on to each one and configure IIS manually. >> > > That sounds like it comes under network admin. > to me, but I actually don't know enough about > running servers to understand exactly what you're > talking about or how useful it is. (Or why you'd > need to copy the same site/configuration to multiple > servers, for that matter. You lost me on that one.) I work in an enterprise environment... Along with my coding duties, I also am in charge of source control mangment and deployment. We have several servers that represent different stages of the deployment process. We have a dev server, a qc server, a stage server, and a production server. We need to push the same code package through each of these environments until production (I should also each of these environments can and do have more then one server). So, we work in dev. When were ready for qc, qc signs off and we push the current code package to the qc server(s). Once the qc has signed off, we push the package to stage where it undergoes user acceptance testing. This environment is an exact mirror of production. When, it is signed off by UAT it gets pushed to production. Each of these pushes is an almost completely automated process. The only human intervention is select environment, push button. For production, there is an additional step - an approver must also push a button, but once done the code is pushed, unpacked, and the IIS website is created if necessary and all settings updated to mirror what was done in stageing. The fact is besides being an awful pain in the butt to have to do this on each and every server manually - it is not allowed by law. I work for a publicly traded company and to be sox compliant our production pushes have to be automated and repeatable. And we have to deploy to stage before prod and we have to deploy to stage in the same manner as prod. The other envrionements don't have the same strict requirments as stage and prod - but, it's dang convinent to just push a couple of buttons and have the code build, packaged, and pushed without doing a bunch of manual work :) I guess you can put this under network admin, but it's really a code deployment tool. It's really the same process that current VS will use to setup and configure a new website when you publish code. -- Tom Shelton
From: mayayana on 2 Jan 2010 15:36 > WMI is not a single technology in the sense of being an independent > free-standing tool, but facilitates working with a variety of management > tools. ie, from a 40k foot view - it is a "front-end" for whatever supplies > a provider. <g> > Yes, but in general it's aimed at providing a consistent style/wrapper for tools used with network admin. In my experience that seems to be mostly how it's used - by network admins managing machines. The term is "Windows Management", after all. And it's Microsoft's version of "Web-Based Enterprise Management". That's all I was getting at -- that it's for network admin and not very useful in most cases for software. I don't even find it very useful in scripting. When Tom referred to "creating websites" it sounded like he was talking about something on the level of web design. But from the sound of his explanation he doesn't seem to be contradicting my description; just adding a footnote.
From: mayayana on 2 Jan 2010 16:15
That's an interesting explanation. Thanks. I have no experience with enterprise (or even people who use words like "enterprise") so your description is a peek into a new environment. The stages of QC and UAT -- the complexity of the whole operation -- seems obvious when you explain it, but I wasn't aware those steps went into corporate websites. (For me QC and UAT are both subsumed under the act of one last quick read to check for typos before I fire up my FTP program and upload the latest edit. :) > > I work in an enterprise environment... Along with my coding duties, I also am > in charge of source control mangment and deployment. > > We have several servers that represent different stages of the deployment process. > We have a dev server, a qc server, a stage server, and a production server. We need > to push the same code package through each of these environments until > production (I should also each of these environments can and do have more then one > server). So, we work in dev. When were ready for qc, qc signs off and we push the > current code package to the qc server(s). Once the qc has signed off, we push the > package to stage where it undergoes user acceptance testing. This environment > is an exact mirror of production. When, it is signed off by UAT it gets > pushed to production. Each of these pushes is an almost completely automated > process. The only human intervention is select environment, push button. For > production, there is an additional step - an approver must also push a button, > but once done the code is pushed, unpacked, and the IIS website is created if > necessary and all settings updated to mirror what was done in stageing. > > The fact is besides being an awful pain in the butt to have to do this on each > and every server manually - it is not allowed by law. I work for a publicly > traded company and to be sox compliant our production pushes have to be > automated and repeatable. And we have to deploy to stage before prod and we > have to deploy to stage in the same manner as prod. > > The other envrionements don't have the same strict requirments as stage and > prod - but, it's dang convinent to just push a couple of buttons and have the > code build, packaged, and pushed without doing a bunch of manual work :) > > I guess you can put this under network admin, but it's really a code > deployment tool. It's really the same process that current VS will use to > setup and configure a new website when you publish code. > > -- > Tom Shelton |