Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Are there any tools for windows like that *nix world has? I am looking for something like Chef or Puppet.
I have found cfEngine but it still looks very *nix centric. Ideally it would be open source, and command line driven.
The idea is to put together an automated infrastructure with windows based servers. Our current IT department does not allow non-windows servers.
Chef is supported on Windows by Opscode. While we don't run Windows for any of our infrastructure, we do have developers who are continually improving our Windows support. We also get community contributions, and most of the early phase Windows functionality for Chef was contributed by the community.
Important: Opscode now provides an MSI installer for Chef on Windows. This makes it easier than ever to get Chef and Ruby installed on Windows.
While we have a lot of Unix/Linux background across our teams, our intention is that Windows is treated as a first class citizen. 2012 will be a big year for Chef and Windows. Keep an eye on the Opscode blog for announcements.
The following Chef Resources work on Windows:
Environment Resource: sets windows environment variables
User
Group
Mount
File
Gem Package
Remote File
Cookbook File
Template
Service
Ruby Block
Execute
That is, these are resources included in Chef itself. As Chef is extensible with cookbooks, many more resources are added through a variety of Windows specific cookbooks. Read on for more information.
You can get started with using Chef and Windows here:
http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Windows
Originally, Doug MacEchern wrote some cookbooks to do a number of things to automate windows, too.
https://github.com/dougm/site-cookbooks/tree/master/windows
This information and more available on the Chef Wiki:
http://wiki.opscode.com/display/chef/Installation+on+Windows
Update
The following cookbook adds new resources to Chef to manage Windows:
http://community.opscode.com/cookbooks/windows
It is an update/rewrite of Doug's fine resources from his repository linked above. Documentation is available on the Chef Wiki.
The following cookbook deploys PowerShell and provides a resource to run PowerShell commands/scripts directly in Chef Recipes:
http://community.opscode.com/cookbooks/powershell
Documentation is available in the README.md included in the cookbook tarball.
Additional cookbooks for installing 7-zip, managing IIS and SQL Server have been added. Our "database" cookbook has been extended with a resource/provider for managing SQL Server databases and users (with the tds rubygem).
The knife-windows plugin for knife adds functionality for interacting with Windows systems to provision them with Chef installation.
Update: We have now added File ACL support for Windows to Chef, for all the usual file/directory suspects.
Cfengine Nova has had stable native support for Windows for years (i.e. no Cygwin is needed).
Everything that is possible on Unix (e.g. run commands, file copy, file edit, etc.) can also be done on Windows, with addition to Windows-specific features like
Registry management
File ACL permissions
Windows service management
Event log support
Advanced OS discovery (version, arch, service pack, network, domain, etc.)
For a short introduction, look in Section 11 of the Nova supplement manual: http://cfengine.com/files/Nova_Supplement.pdf
I have been looking for exactly the same thing.
I ran across Windows PowerShell Desired State Configuration which purports to do many of the CM tasks you'd want to do with Chef/Puppet.
I am not going to give any opinion on it because I am still early in evaluating it - but if you're still looking for something, give this a shot.
Having had a deal of experience here i think that it really depends what you need to manage on a given box. Find your most common use case and ask a more specific question in terms of: whats the best tool for managing that. Things like IIS can be tricky (on older windows builds at least) and finding modules for CM tools to manage things like IIS settings and app pools can be hit and miss - especially when it comes to advanced settings (worker thready recycling springs to mind)
However Puppet has forge modules for more basic IIS settings which largely worked for me - and i really like the declarative format here - especially if you are managing large numbers of IIS servers
Also one of the major issues with Windows and configuration management is the lack of a proper package management solution - what actually comes in really handy here is something called Chocolatey (see http://chocolatey.org/) there is a plugin to use this as a provider in puppet - making the whole management process particularly easy. However i imagine that this can be integrated with other CM tools aswell - but does a great deal to help with installing software automatically in a windows environment
Though it is worth stating that whatever you end up using you will have to spend a while figuring out some odd bugs - windows and scripting/automation is not the best.
Based on my experience, I am glad to use such toolset:
Use powershell to manage the windows configuration. If only windows server, you can remotely execute the ps script.
If you like, suggest to use Puppet or Chef to distribute your powershell script into client.
If you like, suggest to use cygwin + (windows sshd) + crond to manage the shell-likely scripts which run in windows.
I think its better if you can use Microsoft System Center.
It a solution from the Microsoft to manage Microsoft base products form desktops to servers and all. Should give a try ...
How to Deploy Applications in Configuration Manager
Deploying Software and Operating Systems in System Center 2012
I don't recommend Chef unless you are a software developer who knows ruby. Chef is designed for software developers who want to manage IT infrastructure. Not for SysOps people who are the ones that actually end up managing it. It tries to treat IT infrastructure like code which is counter intuitive to how it actually works which is more like just data.
Puppet is more friendly for SysOps people imho but still can be complicated.
The good news is that there are other options as well. Less so for windows but projects like Puppet do support it reasonably well.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have used InstallAware and InstallShield before, and they are pretty difficult to work with and when something goes wrong it is very difficult to find and resolved the issue.
My question is why can't we use a Windows application written using C# to do this.
I understand that .Net framework may not be installed on the destination computer, so I wonder why no one has ever used this architecture:
I will create a simple installer using IntallSiheld(or any other similar tool) to just install .Net Framework and after that extracts and runs my own Windows application which I have written using C# in elevated mode. My application will run a Wizard with Back and Next button and I will take care of everything in it (copying files, creating and starting Windows Services, adding registry values, creating firewall extensions etc.)
Has anyone ever done this, and is there anything that prevents people from doing this?
In essence: don't try to re-invent the wheel. Use an existing deployment tool and stay with your day job :-). There are many such tools available. See links below.
And below, prolonged, repetitive musing:
Redux: IMHO and with all due respect, if I may say so, making your own installer software is reinventing the wheel for absolutely no gain whatsoever I am afraid. I believe you will "re-discover" the complexities found by others who have walked the path that is involved in deployment as you create your own installer software and find that software can be quick to make, but very hard to perfect. In the process you will expend lots of effort trying to wrap things up - and "the last meter is very long" as you curse yourself dealing with trifles that take up your time at the expense of what would otherwise pay the bills. Sorting out the bugs in any toolkit for whatever technical feature, can take years or even decades. And no, I am not making it up. It is what all deployment software vendors deal with.
Many Existing Tools: there are many existing tools that implement such deployment functionality already - which are not based on Windows Installer (Inno Setup, NSIS, DeployMaster and heaps of other less known efforts):
There is a list of non-MSI installer software here.
There is another list of MSI-capable software here.
My 2 cents - if you do not like MSI, choose one of the free, non-MSI deployment tools. How to create windows installer.
Corporate Deployment: The really important point (for me) is that corporate deployment relies on standardized packaging formats - such as MSI - to allow reliable, remote management of your software's deployment. Making your own installer will not impress any system administrators or corporate deployment specialists (at least until you sort out years of bugs and deficiencies). They want standardized format that they know how to handle (that does not imply that they are that impressed with existing deployment technology). Doing your deployment with standardized deployment formats can get you corporate approval for your software. If you make a weird deployment format that does unusual things on install that can't be easily captured and deployed on a large scale your software is head-first out of any large corporation. No mercy - for real. These are busy environments and you will face little understanding for your unusual solution.
"File-Pushers": Those of us who push files around for a living know that the field of deployment is riddled with silly problems that quickly kill your productiveness in other endeavors - the ones that make you stand out in your field - your day job. Deployment is a high profile, low status endeavor - and we are not complaining. It is just what it is: a necessity that is harder to deal with than you might think. Just spend your time more wisely is what I would conclude.
Complexity: Maybe skim the section "The Complexity of Deployment" here: Windows Installer and the creation of WiX. It is astonishing to deal with all the silly bugs that happen in deployment. It is not just a file copy, though it might be easy to think it is. And if it happens to be just a file copy, then there are existing tools that do the job. Free ones too. See links above. And if you think deployment is only file-copy in general, then please skim this list of tasks a deployment task should be capable of supporting: What is the benefit and real purpose of program installation?
Will your home-grown package handle the following? (just some random thoughts)
A malware-infected terminal server PC in Korea with Unicode characters in the path?
Symbolic links and NTFS junction points paths?
A laptop which shuts itself off in the middle of your file copy because it is out of battery?
Out of disk space situations? What about disk errors? And copy timeouts?
What about reboot requirements? For in-use files or some other reason. How are they to be handled? What if the system is in a reboot pending state and you need to detect it before kicking off your install?
How will you reliably install, configure and start and stop services?
How will you support uninstall and cleanup for your application?
Security software which flags your unknown, unrecognized, non-standard package a security threat and quarantines it? How would you begin to deal with this? Who do you contact to get into the good graces of a "recognized binary" for elevation?
Non-standard NTFS permissioning (ACLs) and NT Privileges? How do you detect it and degrade gracefully when you get permission denied? (for whatever reason).
Deployment of necessary runtimes for your application to work? (has been done by many others before). Download of the lastest runtimes if your embedded ones are out of date? Etc...
Provide a standardized way to extract files from your installation binary?
Provide help and support for your setup binaries for users who try to use them?
Etc... This was just a random list of whatever came to mind quickly. There are obviously many issues.
This was a bit over the top for what you asked, but don't be fooled to think deployment is something you can sort out a solution for in a few hours. And definitely don't take the job promising to do so - if that is what you are being asked. Just my two cents.
The above issues, and many others, are what people discover they have to handle when creating deployment software - for all but the most trivial deployments. Don't waste your time - use some established tool.
Transaction: If you are working in a corporation and just need your files to your testers, you can deploy using batch files for that matter - if you would like to. But you have to support it, and I guarantee you it will take a lot of your time. What do you do when the batch file failed half-way through due to a network error, and your testers are testing files that are inconsistent? Future deployment technologies may be better for such light-weight tasks. Perhaps the biggest feature of a deployment tool is to report whether the deployment completed successfully or not, and to log the errors and to roll the machine back to a stable state if something failed. Windows Installer does a lot of this work for you.
Distribution: A lot of people feel they can "just replicate my build folder to the user's computers". The complexities involved here are many. There is network involved, and network can never be assumed to be reliable, you need lots of error handling here. Then there is the issue of transactions: when do you know when the computer is in a stable state and should stop replicating. How often do you replicate, only on demand? How do you deal with the few computers that failed to replicate. How do you tell the users? These are distribution issues. Corporations have huge tools such as SCCM to deal with all these error conditions. Trying to re-implement all these checks, logging and features will take a long time. In the end you will have re-created an existing distribution system. Full circle. And how do you do inventory of your computers when there is no product registered as installed since only a batch file or script ran? And if you start replicating a lot of packages, how many times do you scan each file to determine if they are up to date? How much network traffic do you want to create? Where does it end? The answer: I guess transactions must be implemented with full logging and error tracking and rollback. Then you are full circle to a distribution system like I mentioned above and a supported package format as well.
This "just replicate my build folder to my users" ideas somehow remind me of this list: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing. Not a 100% match, but the issues are reminiscent. When networking is involved, things start to become very unpredictable and you need logging, error control, transactions, rollback, network communication, etc... We have re-discovered large scale deployment - the beast that it is.
Network: and let's say you want to replicate your build folder to 10000 desktop machines in your enterprise. How do you kick off the replication? Do you start all replications at once and take down the trading floor of the bank as file replication takes over the whole network like a DDOS attack? Sorry - it is getting out of hand - please pardon the lunacy - but it really is upsetting that this replication approach is seen as viable for large scale deployment with current technology approaches. Built-in Windows features could help, but still need to be tested properly. You need scheduling, queuing, caching, regional distribution shares, logging, reporting / inventory, and God knows what else that a packaging / deployment system gives you already. And re-implementing it will be a pain train of brand new bugs to deal with.
Maybe we one day will see automatic output folder replication based on automatic package generation which really works via an intelligent and transacted distribution system. Many corporate teams are trying, and by using existing tools they get closer with standard package formats used. I guess current cloud deployment systems are moving in this direction with online repositories and easy, interactive installation, but we still need to package our software intelligently. It will be interesting to see what the future holds and what new problems result for packaging and distribution in the age of the cloud.
As we pull files directly from online repositories on-demand we will see a bunch of new problems? Malware, spoofing and injection? (already problematic, but could get worse). Remote files deleted without warning (to get rid of vulnerable releases that should no longer be used - leaving users stranded)? Certificate and signature problems? Firewalls & proxy issues? Auto-magic updates with unfortunate bugs hitting everyone immediately and unexpectedly? And the fallacies of the network and other factors as linked to above. Beats me. We will see.
OK, it became a rant as usual - and that last paragraph is heading over board with speculation (and some of the issues already apply to current deployment). Sorry about that. But do try to get management approval to use an existing packaging & deployment solution is my only advice.
Links:
Stefan Kruger's Installsite.org twitter feed: https://twitter.com/installsite
Choosing a deployment tool:
How to create windows installer
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
Windows Installer and the creation of WiX
WiX quick start tips
More on dark.exe (a bit down the page)
I'm currently looking for a provisioning-solution to deploy, configure and customize VMs in a vSphere / vCenter environment automatically. By doing that, I would like to adopt some changes to each VM individually (e.g. by using different licence keys for different software products).
During my research, I found that vagrant in combination with the vagrant-vcenter plugin with the help of puppet and git (by having different branches for different kinds of VMs) is doing exactly what i want to achieve:
https://github.com/gosddc/vagrant-vcenter
Unfortunatly, this plugin is immature and still in a beta-state.
Does anyone of you know a suitable alternative (could also be commercial)?
I searched for the same since few months. There is no other way to do that currently except using the plugin and modifying it according to your requirements. There is no other commercial solution currently in place. I used the both the plugins vagrant-vcenter and vagrant-vcloud and I was able to do the basic provisioning stuff without issues. You will not have any issues until you want to customize a lot during deployment. Some of the customization you can achieve through scripts that you can run using puppet after the VM is provisioned on vCenter.
There are several libraries out there to interact with vCeneter. The one I use is https://github.com/rlane/rbvmomi. The code base is somewhat old, but so is vCenter. The Vagrant implementation is great for dev, but has several issues going to full blown staging or production environment. For the latter, a library to interact with the underlying API of vCenter such as rbvmomi is preferred.
I'm probably dreaming here, but am wondering if there's any possibility of completely embedding a minimal CouchDB engine within a Windows application, such that the app can be run without requiring installation (of CouchDB/Erlang) on the user's computer.
I already provide this slimmed down / bundled ability - check here https://github.com/dch/couchdb/downloads and specifically the lean bundle at 16MiB erlang + all couch love here https://github.com/downloads/dch/couchdb/couchdb-1.1.0+COUCHDB-1152_otp_R14B03_lean.7z
Some brief notes on bundling and embedding couchdb on windows at wiki.apache.org/couchdb/Quirks_on_Windows including how to hide the erlang window (erl.exe -detached) at startup.
Ask on CouchDB #user mailing list if you want more info or help while you have a crack at this.
While not a code solution, you could use one of the bundling applications that can embed files and other files into one executable. One example would be BoxedApp.
Why bother. It is so easy to install Erlang on Windows. Just bundle up the whole thing including the erl.exe binary and have your installer unzip it into a folder. The only thing that you would need to change would be the batch files, or better yet, discard them and write your own batch file to start up CouchDb. Also, it is a good idea to use a different port that either the normal Erlang port (or the usual CouchDB port) and maybe even get Erlang to use localhost as its "shortname".
The CouchDB wiki does provide at least a few tips for Integrating CouchDB into your Windows Applications. YMMV, from what I can tell it's more or less just tips on creating a relocatable build. You'll want to likely generate a solid random admin user/password into the local.ini file during the install process and set up proper permissions on all created databases (to protect against any potential cross-site scripting vulnerabilities) in addition to ensuring the socket binding only happens on the default localhost interface.
I'm looking for some type of solution for getting a window dev environment up and running quickly.
Currently we have a large setup document (50+ pages) for doing an install, and I'd like to automate this process as much as possible. The doc includes things like updating environment variables, installing programs, downloading source code, etc.
I know that the majority of these tasks can be done with a batch script, but that's kind of ugly and a lot of work. And while virtualization would be nice, it is not an option for us.
I'm wondering if anything exists for Windows that would make this less tedious. Something like Ruby's Chef would be great. Does anything like this exist for windows?
Well there is Pkgmgr.exe for unattended installation of windows components if you mix it with a powershell script you should be able to get what you want but it wont be as easy as using Chef. Check here for an example of what you can do with Pkgmgr.exe http://learn.iis.net/page.aspx/133/using-unattended-setup-to-install-iis-70/
System Center is the Microsoft way of pushing out standard desktops. It's quite heavyweight mind you.
You could use VMWare for this. Just create a base machine image, with the necessary stuff installed, and point people at the VM.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
As developers, we believe that not having local administrative access is going to severely handicap our productivity. We will be restricted from running IIS (we’re a web development shop), installing applications, running Microsoft power tools, etc. If you’re going through the FDCC process now, it would be great to hear how you are coping with these changes.
Having actively worked as a contract developer at a base that uses the AF Standard Desktop, I can tell you a few things.
1: and most important. Don't fight it and don't do what the first person suggested "and let them choke on it". That is absolutely the wrong attitude. The military/government is fighting lack of funding, overstretched resources and a blossoming technology footprint that they don't understand. The steps they are taking may not be perfect, but they are under attack and we need to be helping, not hindering.
OK, that off my chest.
2: You need to look at creating (and I know this is hard with funding the way it is) a local development lab. Every base that I have worked at has an isolated network segement that you can get on that has external access, that is isolated from the main gov network. You basically have your work PC for e-mail, reports etc.. that is on the protected network. But, you develop in your small lab. I've had a lab be 2 PCs tucked under my desk that were going to be returned during a tech refresh. In other words, be creative with making yourself a development machine +servers that are NOT restricted. Those machines are just not allowed to be connected to the main lan segment.
3: Get the distributions of the desktop configurations. Part of your testing needs to be deploying/running on these configurations. Again, these configurations are not meant for development boxes. They are meant to be the machines the people use for day to day gov work.
4: If you are working on web solutions, be very aware of the restrictions on adding trusted sites, ActiveX components, certs, certain types of script execution that the configuration won't allow. Especially if you are trying to embed widgets/portlets/utils that require communications outside the deployed application domain.
5: Above all remember that very few of the people you work for understand the technology they are asking you to implement. They know they want function X but they want you to follow draconian security rule Y while achieving it. What that usually means is that the "grab some open source lib or plugin and go" is not an option. But, that is exactly what your managers think you are going to do because of the buzz around rapid development.
In summary, it's a mess out there. Try to help solve the problem.
While I've never been through the FDCC process, I once worked for a U.S. defense contractor who's policy was that no one had local administrative access to their machines. In addition, flash drives and CD-ROMs were disabled (if you wanted to listen to music on CDs, you had to have a personal CD player with headphones).
If you needed software installed you had to put in a work order. Someone would show up at your desk with the install media, login to a local admin account, and let you install the software (the reasoning being that you knew what to install better than they did). Surprisingly, the turnaround was pretty quick, usually around 1/2 an hour.
While an inconvenience, this policy didn't really cripple us. We were doing a combination of Java, C++ (MS Visual C++ and GNU/C++), VB 6.0 and some web development. For what little web development we did, we had a remote dev box we would RDP into for testing. Again, a bit of an inconvenience, but it didn't stop us from getting our jobs done.
Without ever having had the problem, today I'd probably try a virtualising solution to run these tools.
Or, as a friend of mine once opined: "Follow the process until They choke on it." In this case this'd probably mean calling the helpdesk each time you needed to have a modification to your local IIS config or you'd needed one of the powertools started.
From what I can tell FDCC is only intended to be a recommended security baseline. I'd give some push back on the privileges that you require and see what they can come up with to accommodate your request. Instead of saying I need to be a local administrator, I'd list the things that you need to be able to do and let them come up with a solution that works (which will likely to be to let you administer your machine or a VM). You need to be able to run the debugger in Visual Studio, run a local web server (Cassini), install patches/updates to your dev tools on your schedule, ...
I recently moved to a "semi-managed" environment with SCCM that gets patches installed on a regular basis from a local update repository. I was doing this myself, but this is marginally more efficient for the enterprise and it makes the security office happy. I did get them to put me, and the other developers, in a special collection so that we could block breaking changes if needed (how could IE7 be a security update?). Not much broke except that now I need to update Windows Defender manually since I updated it more frequently than they do in the managed collection! It wasn't as extreme as your case, obviously, but I think that is, in part, due to the fact that I was able to present the case for things that I needed to do for my job that required more local control.
From the NIST FAQ on Securing WinXP.
Should I make changes to the baseline settings? Given the wide
variation in operational and technical
considerations for operating any major
enterprise, it is appropriate that
some local changes will need to be
made to the baseline and the
associated settings (with hundreds of
settings, a myriad of applications,
and the variety of business functions
supported by Windows XP Systems, this
should be expected). Of course, use
caution and good judgment in making
changes to the security settings.
Always test the settings on a
carefully selected test machine first
and document the implemented settings.
This is quite common within financial institutions. I personally treat this as a game to see how much software I can run on my PC without any admin rights or sending requests to the support group.
So far I have done pretty well I have only sent one software install request which was for "Rational Software Architect" ('cos I need the plugins from the "official" release). Apart from that I have perl, php, python, apache all up and running. In addition I have jetty server, maven, winscp, putty, vim and a several other tools running quite happlily on my desktop.
So it shouldnt really bother you that much, and, even though I am one of the worst offenders when it comes to installing unofficial software I would recommend "no admin rights" to any shop remotly interested in securing their applications and networks.
One common practice is to give developers an "official" locked down PC on which they can run the official applications and do their eMail admin etc. and a bare bones development workstation to which they have admin rights.
Not having local administrative access to your workstation is a pain in the rear for sure. I had to deal with that while I was working for my university as a web developer in one of the academic departments. Every time I needed something installed such as Visual Studio or Dreamweaver I had to make a request to Computing Services.