when I create power platform environments, they show as created by my username, and I'm an admin in that environment.
This causes a problem when creating developer environments, as there's a limit of 3 dev environments per user, meaning I cannot provision more than 3 environment.
I cannot remove myself as a user from other development environments however, so I am effectively limited to creating 3 developer environments.
Am I doing something incorrect here?
Related
I am currently building Non Production TFS 2015 environment. I am restoring database including DBs from production to the new QA DB instance. I performed DB restore using TFSRestore.exe. The restore work successfully.
In TFS QA then I install Application Tier and configure to TFS QA and TFS QA service account.
Then I did RemapDBs, Reset Owner, RegisterDB then start the service. Then I change the Notification URL to point to QA TFS Url.
What is strange is that I can see that in Applications Tiers, I can see 2 machine names display. One is TFS Prod machine and TFS QA Machine Name. How I can remove Production TFS machine name under Application Tier section.
I check the checkbox "Filter out machines that have not connected in more than 3 days"
After 3 days the TFS Prod machine is remove from the Application Tier section. Since I want to do inplace upgrade to the next version therefore is it safe to do this?, how do I know this would not impact the TFS Prod?
I did run the
TFSConfig ChangeServerID /SQLInstance:SPTEST\Contoso /DatabaseName:Tfs_Configuration /ProjectCollectionsOnly
as result, it created new hostID (Guid Number) inside TFS_configuration.tbl_ServiceHost. However, when I select a project in Team Foundation Server I receive an error TF31001: Cannot connect to Team Foundation Server at Project1. The server returned the following error. Value cannot be null. Parameter name: service Definition
Resolve this by delete anything under cache folder
c:\users[username]\Appdata\Local\Microsoft\Team Foundation\5.0\Cache
This is similar post
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ba7caad-4210-4991-b6f0-d4f1dd8c409b/removing-application-tier-server
According to your description, your scenario should be Move or Clone Team Foundation Server from one hardware to another
(Clone option) Reconfigure server IDs and remap databases:
Perform the next set of steps on the new application-tier server if
you intend to continue using the original TFS instance. These steps
are necessary to avoid the risk of corruption of one or both
deployments. If both servers are live, you could end up with
corruption, particularly if they are pointing to the same SharePoint
or reporting resources.
So, please try to Reconfigure server IDs and remap databases. If that still not work, I'm afriad that you have to remove the DB instance and reconfigure the QA envrionment step by step following the instruction mentioned here.
UPDATE:
Seems you just restored an application-tier server but not Move or Clone Team Foundation Server from one hardware to another
For restoring an application-tier server, the name of the old application-tier server remains there is expected (See the end of this article.).
Note: The name of the old application-tier server will still appear in
the list of application-tier servers in the administration console for
Team Foundation. If you select the Filter out machines that have not
connected in more than 3 days check box, the old server will disappear
from the list within three days.
So, to avoid showing the old App Tier machine name you need to follow the steps to Move or Clone Team Foundation Server from one hardware to another as I mentioned in the original answer.
Note: You must install but not configure TFS on the new data-tier
server, and then use the restore function in the Scheduled Backups
node
I am also getting this issue. I followed all the cloning steps to move to my new TFS boxes, and I got it up and running, after running the command TFSConfig ChangeServerID.
But on the new server, under Application Tier > Application Tiers, I see two servers.
The new SQL box, and the old TFS box!
This is on TFS 2017.
I am initiating a huge team to use SSRS for their reporting purposes. Previously I used to develop the reports and send it across to the DBA to implement it, but my recent posting is into a company where they Build once and deploy many process.
I would like to know how reports I developed on DEV environment be pushed into the upper environments with an automated build process.
Thanks
Would like to setup the CI system so that the integration tests could run in an centralized place.
How could we setup a database for each developer for their related branch of work.
We want to guarantee 100% compatibility with the deployed platform, at the cost of having multiple databases which is synchronized with a major db .
installation and data transfer should be automated and not painful during application build.
You have to setup database sandboxes for your CI server. This setup would depend a lot on what database solution you use and the size of your database.
I have developed an application using VB.NET and used microsoft access as the database back end.
Deployment reqiurements : The application is to be deployed on a LAN with 5_15 machines. Any user profile can be accessed from any machine. Any changes to the database entries should be reflected on all machines.
I am confused about how I should achieve this deployment. According to my research :
1.The database should be deployed on one machine . This machine will acts as the database server .
My problem(s) : I am familiar with accessing databases on local machine but how to access a remote database?. How will the connection string look like? Do I need to install ms access on all machines or only on the server machine ? Do I have to deal with concurrency issues (multiple users accessing/modifying same data simultaneously) or is it handled by the database engine?
2.The application can be deployed in 2 ways : i. Storing the executable on a shared network drive on the server.Providing shortcut on desktop of each machine. ii. Storing the executable itself on each machine.
My Problem(s) : How does approach 1 work ? (One instance of an executable running on multiple machines ? :s) In approach 2 , will the changes in database entries be reflected on all machines appropriately? In approach 2, if there are changes to the application , is there any method to update it on all machines ? ( Other than redeploying it on each machine ) Which approach is preferable? Do I need to install the .NET framework all machines? How will i set the connection string to be able to access the database in the network?
Will I have to make any other system changes ( firewall,security,permissions) ? If given a choice to install the operating system on each machine ,which version of windows is preferable for such an application environment ?
This is my first time deploying a multi-user database application on a network.I'll be very grateful for any suggestions/advice,references,etc.
I will try and answer your questions:
Yes you should deploy the database onto a central machine. (Although Access may not the best choice for this sort of thing see: Is MS Access (JET) suitable for multiuser access?)
For connection strings look at this site: http://www.connectionstrings.com/access/
For deployment of your executable you should look at clickonce. This simplifies the install and upgrade of your application significantly. A small learning curve now will reduce your administration headache later.
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.