I've been experimenting with Microsoft's Azure Hybrid Connections and have found that the UI tool for managing the on-premise configuration (called Hybrid Connection Manager UI) doesn't seem to have any way to remove connections once they're added.
It seems that the entries created in the UI tool are simply stored in the configuration file for the Azure Hybrid Connection Manager Service (windows service). So if you edit C:\Program Files\Microsoft\HybridConnectionManager 0.7\Microsoft.HybridConnectionManager.Listener.exe.config and remove entries within the <connectionStrings> element, they'll disappear from the UI tool.
You may need to restart the Windows service and refresh to see that happen.
Related
I have an MSIX application that is being built in the pipeline but each time the application updates and starts it will ask for firewall rule to be added as soon as it makes a call to some http API.
If I go to firewall and check for all previous rules referencing this application it becomes clear why this is happening. So for instance I now have around 20 rules just from testing today and they are all tied to program and look something like this:
C:\program files\windowsapps{guid*}{app_version**}{another_uniqueIdentifier***}\MyApplication.exe
(*) This is drawn from manifest -> identity -> name
(**) There is a powershell script that updates package.appxmanifest version with build number from the pipeline
(***) I am not sure where this comes from
So obviously everytime I build a new version of the application it will receive this value and when I update and run it, firewall will think it is a new application. I doubt this is by design as Firewall would get clogged with firewall rules very soon in some instances where applications receive a lot of new updates.
What am I missing here?
My application (*.wapproj targeting the actual application) is being built from the Azure DevOps pipeline and these are msbuild parameters I use:
/p:ApplicationVersion=$(Build.BuildNumber)
/p:Version=$(Build.BuildNumber)
/p:AllowUnsafeBlocks=true
/p:SelfContained=false
/p:AppxPackageSigningEnabled=true
/p:PackageCertificateThumbprint="$(Thumbprint)"
/p:AppxPackageSigningTimestampServerUrl="http://timestamp.digicert.com"
/p:AppxPackageSigningTimestampDigestAlgorithm="SHA256"
/p:AppInstallerUri="https://ourlocal.server.com/Clients/MyApplication/"
TFS 2015 update 2, release management framework. In server definition, there's a flag whether this server should access the drop location via straight UNC, or via HTTP(S) to the Release Management Server (RMS). Question: which builtin actions/tools are aware of this setting? The "XCopy Deployer" tool, and "Copy File or Folder" action, which is based on it, definitely don't respect that setting - it just tries to xcopy straight from the source UNC path.
The only UI that mentions drop location is the custom component creation UI.
All of the built-in actions work with this setting. So do custom deployment tools, for that matter.
The way it works is as follows:
The normal behavior (directly from UNC) has the Agent reach out to the drop location directly in order to stage the files in a temporary location on the machine on which the agent runs. This folder is usually C:\users\<service account>\AppData\Local\Temp\RM\T\RM\ if I'm not mistaken. After that, it runs the deployment activity against the staged files.
The other option (via HTTP) has the RM server reach out to the UNC path, then serialize the files over HTTP to the agent machine. After that, it runs the deployment activity against the staged files.
Basically, all that flag does is change the behavior of how the files get to the target box. It doesn't change the behavior of the commands that are invoked.
However, it's entirely possible that the UNC vs HTTP option is ignored when using a component that points directly to a UNC path; that behavior I haven't tested.
Since you're using TFS 2015.2, you should look into retiring your Release Management server and migrating to the new web-based experience. The ALM Rangers have a migration tool available.
Can you please confirm one thing:
When you use the option “Through Release Management Server over HTTP(S)” it’s important that the Service account were RM is installed with has modify rights on the drop location.
if you want to use Server option, this is something by design:
With agent based flow, we don’t support “build drop on server” and “drop via HTTP on RM” together.
If you want to have these options, then you can use vNext workflow which will support both.
It ideally should work with xcopy.
Please drop me an email atdmittal#microsoft.com if things still does not work...
My ASP.NET MVC project pushed to a Azure website with an extra DLL which is invalid. This is keeping the project from running correctly. If a new website is created it works perfectly. Cleaning the project locally and redeploying does not fix the problem. Is there a way to perform a "remote clean?"
This project is being deployed directly from Visual Studio with the publish menu item.
When you right click and click Publish Web on the left hand side there should be a settings tab. Click this. Then expand the option under File Publish Options and check the Box for Remove addtional files at destination. (This will wipe out whats already there)
Also can be detailed here: MSDN
Another trick to delete an entire Azure website deployment which can be done entirely in the Azure portal is:
1) Create a new empty deployment slot under the Azure website.
2) Swap it with the parent Azure website.
That will give you an empty Azure website. If you want you can delete the deployment slot afterwards.
You can also use console to delete any file. Kudu is a web tool that allow you to see inside of Azure web application.
Two ways to access Kudu
go here: https://yoursite.scm.azurewebsites.net/DebugConsole/?shell=powershell (replace with your real website name)
login to portal > app services > your site > Development tools > Advanced tools.
You can also delete files via Webmatrix (link in footer menu in Azure configuration portal)
Download the profile from Azure portal
Import publish profile in VS
Stop the web app in Azure portal
Stopping the web app ensures existing files including dlls and other resources will be deleted after publish succeeds.
This step might not be necessary, however, the existing web app could have some dlls that cannot be removed during publish directly, returning error messages like:
Web deployment task failed. (Unable to perform the operation ("Delete
File") for the specified directory ...
4. Publish with “Remove additional files at destination” checked
Start the web app again after publish succeeds.
for linux servers you dont get, CMD, then all you have to do its, Delete the deployment, then create deployment credentials for FTP and there you go with FTP client clean the wwwroot folder by your self.
So, I'm currently in the process of moving a client from Surround SCM to TFS. For some reason unknown to me they have a really hard time setting up a dedicated IIS for the app tier of TFS. Now they already have both an IIS and a SQL server for their regular intranet/internet apps, so I thought why not sjust use the existing server?
So my question is: Would it be ok to install TFS App Tier on the existing IIS server or reside on its very own dedicated server?
TFS should live fairly happily with other IIS applications however you must have your Sharepoint instance configured to be equally happy with other services. TFS is not happy if installed on a domain controller, but provided IIS has all the pre-requisites, this is the only TFS AT on that server, no other sites in IIS are listening to port 8080 and you keep the TFS instance in it's own application pool then I think things should work out but I have never done it in that order. I've had additional applications running on the IIS instance set up for TFS when TFS was set up first - but not add a TFS instance to an existing production IIS instance.
That said, I would be very tempted to have TFS on it's own IIS instance. As the version control and work item tracking system is usually fairly critical to the life of a software development organization you want to make sure that this critical server is not affected by other applications in the organization. You want it to have the love and attention given to a production environment. Also - when you are getting started with installing TFS you can sometimes run into issues. Being able to wipe the box clean and start all over again ensuring you are following the installation instructions step by step is a handy fall back position (more true in the TFS 2005 days than now, but old habbits die hard).
Additionally, TFS comes with a license for SQL Server provided that SQL Server instance is only used for the TFS application.
Because of all this, I would rather have a TFS server running the Application Tier and Data Tier on the same server than have an AT on a share IIS box. I think I would even rather have the application tier running on a virtualized environment running on that shared box.
There seems to be a fault with my access to directories on Team Foundation Server.
See the image below.
I'm the only one with this problem. All of the other clients can connect to the server fine, so it must be my local copy of Team Foundation Server thats gone haywire.
Any ideas?
This is usually a permissions problem. Use the TFSAdmin Tool to check permissions on the SSRS and Sharepoint systems (which are separate from TFS itself, unfortunately). Check that the settings are working the way you intend by browsing directly to the Reporting website & the Team Project Portal from inside IE.
There are other possibilities, however.
Check the Application event log on the server to see if your attempts to connect generate any exceptions.
If you're using SQL Server 2008, make sure you have Team Explorer fully patched up to 2008 SP1. (you'll need to re-run SP1 if you installed Team Explorer afterward)
Make sure you're connecting to TFS using the same URI as other people. If you're using a fully-qualified domain and they aren't (or vice versa) you could be exposing a server configuration problem in TFS's Registration database. Details here: http://blogs.msdn.com/buckh/archive/2007/03/31/configuring-team-foundation-server-to-use-fully-qualified-domain-names.aspx Also, there is a known bug in the admin util: http://support.microsoft.com/default.aspx/kb/959126
Check, recheck, and re-recheck your proxy settings. Both software configuration (TFS inherits them from IE / Control Panel) and at the network level (whether you're on some LAN segment that gets proxied differently). Use an HTTP protocol analyzer on a good & bad machine to be certain.
I had the same issue after trying to connect to alternative address of our TFS server.
In my case it seemed that it just cached the previous TFS address although I changed it back to the original address.
What fixed it for me was to delete this folder:
C:\Users\<user>\AppData\Local\Microsoft\Team Foundation