I'm getting requests from 'the Field' to make my agent deployment 'easier' but I'm at a loss as to how.
Right now, I provide a user Interface to install and configure the agents.
To deploy the agents, I relied on older Windows technologies, here are the steps I use:
Start dependent services via remote SCM
Copy the agent.MSI via the File Administrative shares
Configure the agent's settings via remote registry calls
Use WMI to remotely silently run the agent.msi
Use the Administrative shares to move the agent.msi to the program folder (for uninstalling later)
To allow all these steps to happen, I need:
1. the firewall to configured correctly
2. the 'installing' user has to have admin access to the remote computer
3. Remote File Admin shares have to be turned on.
4. (I turn on WMI and Remote Registry remotely)
This deployment system was built back in the 2003 days.
Is there some better way now? Maybe a deployment library I can use?
thank you.
The best you can do here is to create a properly behaving .MSI that supports silent installation. It is then up to your user communities to plan their own deployments using the tools of their choice such as SCCM. Much more detail is required in order to give exact suggestions.
Related
I am working on an installer of a windows application. Due to its dependencies, to make it work, multiple applications need to be installed and also some changes to the windows features (turning on some windows features) are required.
My installer is supposed to be used by companies. In companies, it can be the case that someone has the rights to install software (in program files folder) but is still restricted (for example updates are regulated by the IT department). A typical explanation for this is that someone is a local admin but not necessarily a global admin.
Can it be the case that someone is allowed to install software in the program files folder but restricted in enabling windows features? I need to know this because this would simply mean that my installer should not automatically/automated enable such windows features. It may work on my VM, but it can fail on the customer employee desktop which would cause the installation to fail due to missing rights for one specific action: enabling some windows features.
Can enabling Windows Features be blocked for local admins?
According to this answer there's no group policies to control Windows features. Therefore we could assume that you're safe for now.
I have installed a SCCM system. My problem now is that I don't know how to integrate clients that are on the same network like the SCCM.
I have already created a location in the SCCM-Console and i have to integrate application software into the SCCM.
The Testclient already has a Windows 7 installed.
My question: How do I connect a client with the SCCM?
It kind of seems like you are potentially asking a few different things here so I will give an answer to what I think you are asking and hopefully that helps
1. To add computers to sccm so they show up in your management console, you can either do it manually or via discovery. You can configure discovery in the administration tab. Normally you will want to discover computers from your AD setup.
2. To install the sccm client on the computers, you can either do it manually by running the software on the PC. Alternatively you can push out the client to computer by right clicking them and pushing out the client there.
3.To add software to sccm you can go to the software library tab and create either packages or applications.
Hope this helps.
You need to setup boundaries and boundary groups within SCCM based on subnet or AD sites.
Take a look at this example: http://shabaztech.com/sccm-2012-r2-client-installation/
If you have discovery turned on, you should be able to right-click a computer object within the SCCM console and install the client, assuming you have the proper accounts and firewall rules setup.
Looking for suggestions on how to go about the following, i.e what would be the best language to do it in etc, third party tools are a no :(
I've been tasked to create some sort of windows shell/command line interface that will allow a standard users to install a specific set of applications (configurable by administrators) (installation requires Admin/UAC elevation) due to security restrictions the user cannot have elevated privileges so they'll be able to run the shell as a standard user and it would have hidden/encrypted credentials built in to run the installs as.
Some of the requirements are as follows:
It would need to work on Server 2008 R2, 2012 r1 and 2012 r2
The credentials used to perform the install would have to be hidden (encrypted) from the end user.
Ideally it could work by us providing some config to it prior to handing that server over to the customer and limit what it could be used to install to a particular .exe or .msi (so we know of a need to install an app, we are advised of the name of the install and can logon and can enter it into a form maybe so only that app can be installed, then hand the server over to the customer who runs the same utility or shell extension or whatever and can then install their app.
Even more ideally it was more intelligent than that and some means of ensuring any .msi was indeed installing the application that the msi name related to (seems unlikely but just in case a normal user created an .msi to grant himself further admin access as per http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevated-is-equivalent-to-granting-administrative-rights.aspx )
Ideally its lifespan would be limited in terms of time (unsure if this could be for example to x number of days).
Any pointers on how to go about this, seems like a good challenge :)
Thanks for reading all that!
Mike
Thanks for the responses,
I managed to do this in C#, with no prior experience in the language :)
The application has 2 parts to it, a GUI and a service. It works by having the application send an install command via IPC to it's counterpart elevated service. (Thanks Hans Passant for pointing me in the right direction there). The service initiates the installer under it's own elevated account but displays the installer GUI on the users session. Files are HMACSHA1 checksum validated prior to install, on both the app and the service.
Thanks,
Mike
If a user requires the ability to install application in the Program Files folder, then instruct the domain administrator to give Full Control of the Program Files folder to Everyone:
Just because the default setting forbids standard users from modifying programs, doesn't mean you have to keep it that way. Windows is a secure operating system that gives you the capability to keep it secure.
If your administrator only wants some users to be able to modify the contents of the Program Files folder, then only give that permission to certain users.
The better solution is to re-design the applications so that they do not install in a (by default) protected location. Have them instead install in:
%APPDATA_LOCAL%\Contoso\Frobber\Grob.exe
e.g.
D:\Users\Ian\AppData\Local\Contoso\Frobber\Grob.exe
A user is always allowed to write anything in their own profile folder.
I have successfully captured an image using sysprep and can provision new machines from it, however all the custom user settings are missing (desktop shortcuts, chrome bookmarks etc...).
A more serious issue is that one of the applications I had installed fails on the provisioned machine unless run as administrator (due to the way it writes some files when being installed originally).
How can I ensure this profile information is preserved and I don't hit the permissions issue for the application?
I have been pointed at the following link (http://theitbros.com/sysprep-xp-sp3-copy-administrator-profile/) but it seems to be Win XP specific.
Profile information can be migrated to a new deployment using the User State Migration Tool (USMT). USMT is a free tool designed to help IT Professionals migrate files and settings to Windows 7 or Windows 8. USMT captures user accounts, user files, operating system settings, and applications settings and then migrates them to the new Windows installation. The TechNet articles ‘Step-by-Step: Basic Windows Migration using USMT for IT Professionals’ and ‘User State Migration Tool 4.0 User’s Guide’ are good places to start learning how to use USMT.
For your application issue, I would recommend using the Microsoft Deployment Toolkit (MDT) for your deployments. MDT can deploy your image and then install device drivers and applications to the machine automatically. These two video walkthroughs are specific to migrating from Windows XP to Windows 7 with MDT, and using USMT to migrate the user files and settings:
Part 1: Building the Deployment Environment
Part 2: Initiating the Install and Migrating the PC
There is also a Microsoft Virtual Academy 7 part course titled ‘Migrating from Windows XP to Windows 7’ that has two parts dedicated to using USMT to transfer user data and one part for MDT.
MDT can be downloaded here, and USMT is a part of the ADK which is a component of MDT.
Hope this helps,
The answer here wasn't very elegant (in my mind at least) but here is what I did to achieve the desired result:
Create the VM as usual (specifying the admin user during setup)
Create a new (non-admin) user and give them RDP access
Log in as the non-admin user
Install all the necessary software
Log in as the admin user, change the permissions for any files that were causing an issue to be readable by the non-admin user
Run sysprep as the admin and complete the process as detailed elsewhere
This gave me an image that I was able to provision VMs from. When creating the VM I specified the admin user to be created (but then never needed to login as the admin, as I would just login as my non-admin user that was created before). All profile settings for the non-admin user are preserved.
Hope this helps anyone else facing the same issue.
Our company produces cross-platform software and we have Bamboo instance which is building projects under various incompatible environments (linux, win, os x). There's a VM configured for building under each environment. So is it possible to run several remote agents on each VM to perform concurrent builds of different projects ?
Yes, that is possible. See the "Changing where the remote agent stores its data" section of the Bamboo Remote Agent Installation guide.
To make this work, for each remote agent you run on the same machine you will need to specify a different location defined for the agent to store its data (otherwise builds will fail trying to write to the same location).
Yes it is possible to run multiple remote agents on both windows and linux based hosts. I currently manage the remote agents for the linux hosts so I can't comment on the windows service remote agents.
I implemented the multiple remote agents buy first creating a folder for each agent, then on installation of each agent you specify the location for the bamboo.home of each agent.
On the bamboo master server you can rename the remote agent so you can tell the difference between the agent that is running you build job.
I can't comment on linux, but on Windows, yes you can.
If you change the Windows service name from the default 'Bamboo Remote Agent' to something like 'Bamboo Remote Agent 1', 'Bamboo Remote Agent 2' by:
uninstalling with the bin/uninstall-ntservcice
editing conf/wrapper.conf to change the service name and display name
reinstalling with the bin/install-nt-service
After doing this you should be able to run multiple agents fine.
I was able to create two agents on the same server. In this case I actually want the same bamboo-home set so that either agent can build to the same location ... just when some of my builds take longer, I have a second agent sitting around for the quicker builds that get queued up otherwise. In the bamboo-agent.sh, I changed:
APP_NAME, APP_LONG_NAME, and REAL_DIR
I didn't change anything in conf/wrapper.conf. And in the GUI I updated the name of the agents by clicking "Edit Details" on the agent capability page.
Just in case, I also made the agentUuid tag in bamboo-agent.cfg.xml empty thinking it would get overwritten when I started the agent. I didn't want to agents starting with the same Uuid even though I couldn't tell what this field was already used for.
As far as I can tell this worked as I expected. I could see two agents from the GUI and kicked off two builds simultaneously. FWIW, what I don't know if this is considered a hacked way of doing this or not.