I want to run BizTalk server 2010 on windows 7. Problem is my company’s management does not want to give local administrator rights to developers. Can I perform BizTalk operations (like start/stop/create/ delete host and host instances, publish website on IIS, deploy services, import/export MSI and bindings, create SSO and BRE entries, etc) without local administrator rights.
I also need to work on ESB toolkit.
I want to confirm that, due to the absence of local administrator rights, would I stuck or be in trouble at any stage of BizTalk service live cycle ? and is there any way around to overcome those issues ?
Thank you,
Best answer: Can they provision a VM of Windows Server 2008 R2 for you where you can be a local Administrator and run BizTalk Server? Even the most security conscious environments I've been in allow this.
To address your specific question: No, you don't need to have local Administrator, but...there are a number of tasks during BizTalk DEV that require a very high level of privilege on the system, such as creating and managing Services, deploying/installing applications, managing the Global Assemble Cache and probably a few more.
So, by the time you get all the system rights to do these, you're pretty close to being a local Administrator anyway.
Either way, a VM is still the preferable option. Technically, it doesn't even have to be joined to a Domain so you'd really be in a sandbox.
Related
We recently migrated from VS 2008 to VS 2013 including a set of setup projects. One of the setup projects is meant to install a web application. It has one custom action that is meant to check the connection to the database. The code of the custom action has not been touched during the migration and the .msi works perfectly when generated from VS 2008. When I built the .msi from VS 2013 it works perfectly well when installing on our local development server, and throw an error saying that it cannot connect to the db when rolling out in the clients environment.
I'd really appreciate if anyone can point me into direction of search here. I know that I'm passing a correct connection string, and .msi generated from VS 2008 can connect to that db from the same server.
Visual Studio custom actions that are installed for Everyone will run with the local system account. Connecting to a SQL DB will often fail because the DB doesn't allow the system account to connect, or because the DB is on a network share and the system account has no network privileges.
So it could fail because of the security settings of the DB or because the DB is on a network, and it may be nothing to do with the server. It might also connect if the install runs with a Just me setting because the custom actions then will run with the installing user's credentials. There may also be issues with architecture because servers are 64-bit and the 32-bit subsystem is optional, and you didn't say whether you install was x64 or your custom action code.
I want to connect to TFS through the Team Explorer in Visual Studio 2015.
So, my problem is that I cannot connect because of a wrong authentication (valid username and password, valid privileges).
I think the reason for that is the Domain but I never joined one because I use a normal version of Windows 10 Enterprise. Could it depend on installed features like WCF? I did really intensive research but I'm not able to find any information to solve my problem.
Here is a screenshot of the Login-Dialog:
On premise TFS only supports Windows auth (either local or domain).
If your TFS server and VS are installed on the same machine, you could use your local account with enough permission to connect TFS server directly.
If your TFS server and VS are installed on the different machine, and since you haven't joined domain. Suggest you to join domain : This is the easiest to setup, user-wise. All you have to do is be a member of the domain and a member in a team project. Another option is using Visual Studio Team Service (TFS in the cloud) for this. It's currently free and uses Microsoft live accounts instead. Which you can access it everywhere on the internet.
First I want to thank you for your support.
I'm sorry that this comes late but I already solved my problem.
I obviously just forgot to put a Backslash in front of my username so that I don't use the domain of my local computer.
My company is interested in better integrating our investment in VMWare with our TFS deployment. Currently the company is running TFS2005 SP1, VS2010, and we have a sizeable SAN that we would like to use in environment reproduction similar to what is offered in TFS2010 Lab Management.
Of the features offered by TFS2005, we are currently leveraging only TF Version Control--work items and build automation are handled by separate systems. However, we would like to use the TFS-integrated Symbol/Source server in order to accurately debug the different versions of our product, and that's where we're running into difficulty.
The VMs deployed in VMWare are not joined to the corporate domain, and this means that we run into difficulty when attemping to grab source code information via Source Server and the "tf.exe view" command.
If devenv is run on the VM, it can't authenticate a domain account, and tf.exe view fails when grabbing source info.
If devenv is run on the developer desktop and debugging is done with remote debugger, the vm's local user account fails to access the share exposed by Symbol Server and can't load symbols to begin with, much less retrieve source.
Has anyone done this before?
Yes - You can still do this. If you are using Windows 7 (and I believe Windows Vista) you can always add the domain credentials to the "Credentials Manager" in the Control Panel. This will help it authenticate for the TFS URL whenever it needs to talk to TFS.
BTW, I have a blog post discussing the Symbol Server and Source Server features of TFS 2010 available here: http://bit.ly/SymbolServerTFS
We work on XP Pro workstations and use Visual Studio 2008 & 2010 to develop winforms, web and web services against local IIS and SQL Express instances.
We currently have local admin rights on our main machine account. The proposal is to move to a low rights account for our amin login but to have another local account with local admin rights that we then use to elevate where needed.
Are there any issues developing and debugging under this setup that would affect developer productivity?
From experience you can't install things like NUnit in your reduced priviledge account - that shouldn't be a problem for you as you can just type in the details of your higher priviledged account (it was a problem for us as we didn't have that). Also you'll need to do a similar thing if you're firing up services / IIS, etc. Again as you have it to hand it shouldn't be a problem.
My conclusion was that you could develop as a non-admin as long as you know the admin password - but if you don't know the admin password, you are going to be in for a very frustrating time!
What needs to happen before we can open Web Application Projects hosted in IIS7 with Visual Studio 2008 without running as Administrator? Are we talking about waiting for the next version of Visual Studio? Are there any existing workarounds?
I think it's implied by the above, but this pertains to Vista.
Thanks.
Never is a bad option - pretty much all other development I can do as a non-admin. Its not as if the code under IIS requires admin rights either.
I'd like to see an IISAdmin group which grants a developer's user account permission to manage IIS without granting full adminstrator privileges to the entire PC.
My guess is never. I think admin rights will always be needed to change websites and virtual directories in IIS.