First off, I read all other Questions, that relate to this, I did an extensive google search on this topic and could not get a working answer.
I installed the Community Version of Visual Studio 2015 in mid November and been using it since then. After finishing my project, I went back to pen and paper for new formulas and noe came back to implement all those neat things.
Now it says, that my trial license has expired and should be renewed. I already read, I should use my MicrosoftAccount to do that, and proceeded by doing that.
Now this happened
It says, I should check firewall and prxoy settings and I read about contactiong the administrator. So that, what I did, but he says, there is no proxy, no block by firewall or anything else.
When running VS as administrator (after entering my credentials) I can create new projects and debug existing ones, so no problem there. However I can not use the program as normal user.
I read somewhere here to try repair it via systemcontrol, but that did not work either.
Does anyone has a solution?
In addition: There is also no "Enter License Key here" field, so that is also not an option.
(several Days later)
Halleluja, I found the answer! After digging through some Microsoft Help-Forums, I came upon this Thread, that not only perfectly describes my problem, but also gives a solution. So dear visitor from the future, who googled the problem and came upen this Stackoverflow Question: Follow the link above!
So, after sniffing packets harder than a drug addict, trying to find a difference in TLS exchanges between my computer and VS licensing server when using a domain account and when a using local account, and noticing no difference, I recalled why I had pushed this hypothesis to the side: our network supports TLS 1.2 perfectly well, as I can connect to TLS 1.2-only remote hosts without any issue.
This means the issue lies elsewhere, and is caused by Visual Studio treating domain accounts and local accounts differently when trying to renew licensing information.
The good news is I've found why and how to fix it.
I recalled that earlier this year, when we upgraded our commercial department from Windows 7 to Windows 10, they all encountered issues while trying to configure their mail accounts on Microsoft Outlook: an unknown error 0x8004011c. If you search around for it you'll quickly find that this only happens when using domain accounts and not when using local accounts (sounds familiar, heh?). The fix to bypass this issue is to set a specific Windows cryptography-related registry key.
When digging a little deeper, you can find that this fix is related to KB 3000850 (which I sadly cannot link to due to my account not being verified) and is actually described in the "Known issues" section, as well as in Samba-related documentation ("Required Settings for Samba NT4 Domains").
In short: Windows 8.1+ clients (with KB3000850) joined to an NT-Style domain are not able to use Windows Credential Manager. This doesn't occur when not using a NT-Style domain. The fix seems to globally authorize using Windows Credential Manager whatever the domain context.
So, to wrap it up, if:
You have a NT-Style domain (such as when using a Samba domain controller)
You have Windows 8.1 or later
vYou encounter issues when renewing your Visual Studio license
Then, set the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001
This solved the issue on our domain, for all machines and accounts tested.
As to why Visual Studio 2015 needs to use Windows Credential Manager and not Visual Studio 2013, someone from Microsoft will have to chime in there to explain because I have no clue.
You are using a very old Samba server that uses unsupported features. NT4 came out in 1995. Active Directory didn't exist back then. A lot has changed in the last 20 years, including strengthening security and gradually removing older, less secure features like LanMan and NT4 domains.
Instead of weakening security, you should follow the advice posted in the page you linked, Required Settings for Samba NT4 Domains:
Microsoft discontinued the official support for NT4 domains in their Windows operating systems. ... Anyway, consider migrating to a Samba Active Directory (AD) to avoid problems if a future update from Microsoft disables or removes the unsupported NT4 features.
Related
I have a client site running our Windows desktop software on a number of computers with 64 bit Office 365.
On most of their computers, our software is able to send email via Outlook.
However, two of their computers were upgraded to 365 last year (by their IT technician, not us), and both fail when they attempt to send email from our software.
Outlook works fine on its own, and so does our software - on both of these computers. But these two both can't send email from our software. (The other computers, which send email fine, are running exactly the same version of our software.)
When sending email, our software first checks for the existence of "Outlook.Application" or "Outlook.Application.*" keys in the Windows Registry to determine whether Outlook is installed. If not found, our program logic assumes that Outlook isn't installed, and attempts to use MAPI instead to send mail through another email client like Thunderbird (or through Outlook using MAPI). However, these computers both then crashed, because MAPI doesn't work on 64bit computers.
When I investigated these two problem computers, I found that they both had no "Outlook.Application" or "Outlook.Application.16" keys anywhere in their Windows Registry. I have never encountered this before. How and why would Office 365 install without creating these Registry entries? (I had just installed Office 365 on two computers here in my office, and they both had these keys and worked perfectly. And we have never encountered this before, at any of our other user sites.)
I discussed this with their IT technician. He did a complete uninstall of Office 365, and installed them from scratch, using the "on-line" install (that I had used on my computers - I sent him the URL to be sure). However, after this they were still unable to send email. When I investigated, I found that the Registry keys were still missing.
Their IT technician then asked me to export all the "Outlook.Application" and "Outlook.Application.16" keys in "Computer\HKEY_CLASSES_ROOT" and send them to him. He imported these on both those computers, but it did not fix the problem.
However, because the keys now existed, our software then attempted to send email directly through Outlook, using OLE. However it crashed on the line where it tried to create an Outlook Application Object:
loApp = CreateObject("Outlook.Application.16")
I built a special version with some extra test code in it. After failing to run the above line, it tried to run a line:
loApp = CreateObject("Outlook.Application")
This also failed - presumably because some Outlook application components have not been installed.
I did some fairly extensive Google searches for posts that might identify a solution, but found nothing that seemed to fit. A couple of posts suggested running an Office "Repair" from the installation tool.
I mentioned this to their technician, and he did this. Interestingly, when I then checked (using RegEdit), it had created a lot more "Outlook.Application" and "Outlook.Application.16" Registry keys. But our software still fails on both the "CreateObject" lines in that test version, and single "CreateObject" line in the normal version.
Both their technician and I are completely mystified (and now out of our depth in the Microsoft black arts of Office 365 installation and Windows).
Has anyone encountered this scenario before, and / or can suggest where we might go from here?
OK, the original post was getting a bit long, and I didn't want to clutter it with too much information. So here is some further info:
In answer to Eugene's questions:
Using RegEdit, I searched the entire Registry - for one of the
computers that didn't work, and one that did (plus my own here,
which also worked fine).
Their technician installed the latest 64 bit 365. If I understand
correctly, the initial install was done from an ISO file. When that
didn't work, he tried again using the "on line" install (which I had
successfully used here). He used the "on line" install again for the "repair". I don't have current build numbers, but could obtain these later in the week if relevant. But they should be up-to-date.
No we can't reproduce the problem ourselves in-house, and have never
seen it before at any other client site.
The site is running the same antivirus software on all computers (those
that work, and those that don't). So I suspect that this won't be
the cause.
Registry keys that match perfectly on those two computers are:
Computer\HKEY_CLASSES_ROOT\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_CLASSES_ROOT\Outlook.Application
Computer\HKEY_CLASSES_ROOT\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Backup\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocServer32
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\RegisteredApplications
Something that may be significant:
The Windows Registry on the computer that does not work has four extra keys (that are not in the computer that does work):
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
That computer (which doesn't work) also has a folder C:\ProgramData\Packages\Microsoft.Office.Desktop.Outlook_8wekyb3d8bbwe\ with 3 subfolders in it (with system generated names):
The first (created in 2019) has a subfolder "\SystemAppData" which is
empty.
The other two (both with same date/time in early 2020) are completely
empty (i.e. have no SystemAppData subfolder)
I wonder whether these keys may somehow be causing mischief. Early next week the technician and I plan to back up these keys, and then delete them.
Does anyone know what these keys are about?
(I found a blog that may be relevant: https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/ But then again, it may not be.)
Keep in mind that older version of Windows Store Outlook ran in a sandbox and was not externally accessible. Uninstall it and reinstall again from the store - you will get a regular C2R version.
Eureka!!! Deleting those extra legacy Registry keys did the trick.
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Our software immediately was able to create Outlook Application objects, and send email via Outlook.
It seems that these extra keys dated back to an earlier attempted install by the client (before their current technician became involved). There were about 20 or so other 'Outlook*' keys in that part of the Registry with '8wekyb3d8bbwe' in their name. I subsequently deleted these too - on the the assumption that they were all legacy garbage. (As a rule, it is pretty dangerous to delete things you don't understand - but so far, so good. Although I am too chicken to delete a host of others in that location for Access, Excel, PowerPoint, Word with with '8wekyb3d8bbwe' in their name too.)
I had the same problem; it came from a brand-new computer!
What worked for me was the early binding. Select: Tools > Reference > Microsoft Outlook 16 object library.
Dim objOL As Outlook.Application
Set objOL = New Outlook.Application
Set objOL = Nothing
At the end, setting objOL to Nothing is crucial, otherwise the instance stays open, and it causes problems with Outlook.
Reference.
After installing VS2019 16.5.1 and 16.5.2 I receive a message that Windows Defender has locked some features of Xamarin.Messaging.Broker and asking if I should allow it.
Normally I would as it seems to be part of Visual Studio but this executable is located in my appdata\local\temp file, which I would not expect it to be. Searching the net for info about this yields little in the way of good information.
Does anyoe know what it does and why on earth would you put an exe in the local user temp?
My message appear exactly after upgrade 16.5.0 to 16.5.3, We all see this message in 16.5.2 version and above.
So as far as we know this happened because microsoft add something new in 16.5.2 and above, It can't be anything except microsoft work since we all have seen this firewall message.
My file was in C:\users\username\appdata\local\temp\xamarin\xma\broker.local\16.5.000.533\broker.exe
This access will add a record in firewall advanced "Inbound Rules" Which means grant an access from outside to our PCs on UDP/TCP.
Conclusion :
Personaly i allowd this file in firewall because i have tons of problems in xamarin (special to connect to Mac) and i don't want to add more, I suggest you all do the same.
I don't know why it would be in that location, but this article lists the endpoints to allow for a xamarin firewall configuration. Perhaps it might assist in some way.
https://learn.microsoft.com/en-us/xamarin/get-started/installation/firewall
In VS2022 I just had this security alert just as I went to open the toolbox to add a Button to a new WPF project.
**Windows Defender Firewall has blocked some features of this app**
Name: Broker
Publisher: Xamarin
Path: C:\users\username\appdata\local\temp\xamarin\xma\local\broker\17.3.0.288\broker.exe
Allow Broker to communicate on these networks:
✔ Private networks, such as my home or work network
I refused it.
One person on my team found their VB6 IDE was no longer working. We eventually realized that the file VB6.EXE (from C:\Program Files (x86)\Microsoft Visual Studio\VB98) was missing and that this was because Symantec Endpoint Protection (14) had removed it due to WS.Reputation.1 (noted in Symantec logs).
I tried copying back the EXE from another PC and you could literally watch the file disappear from Explorer within a couple of seconds of being copied. Fail.
This only occurred on this single PC. Everyone here is using VB6 and has the same antivirus, so it is confounding why it happened only to a single person.
Could there be some factor unique to this one PC that caused this? If so (or if not...) how can we work around this?**
Other details:
New-ish PC, in use for about 2 weeks
VB6 had previously been working
Windows 10
Symantec Endpoint ver 14, corporate environment / centrally administered
Symantec's docs for WS.Reputation.1:
WS.Reputation.1 is a detection for files that have a low reputation
score based on analyzing data from Symantec’s community of users and
therefore are likely to be security risks. Detections of this type are
based on Symantec’s reputation-based security technology. Because this
detection is based on a reputation score, it does not represent a
specific class of threat like adware or spyware, but instead applies
to all threat categories.
The reputation-based system uses "the wisdom of crowds" (Symantec’s
tens of millions of end users) connected to cloud-based intelligence
to compute a reputation score for an application, and in the process
identify malicious software in an entirely new way beyond traditional
signatures and behavior-based detection techniques.
Report this false positive to Symantec to have it properly resolved:
https://submit.symantec.com/false_positive/
I submitted to Symantec and after 1-2 days I received the following reply:
Upon further analysis and investigation we have verified your
submission and, as such, the detection(s) for the following file(s)
will be removed from our products:
File name: VB6.EXE
MD5: 8AC4F5C29334B3C1B667B92EF860023A
SHA256: 971F73C9AC27EF3D50C1AC36D154674AB3A9957F967BFF6A62D5D18A75CFD910
Note: Whitelisting may take up to 24 hours to take effect via Live Update
Since I assume this is a truly global change, perhaps if this works it will work for other people also. However as noted above they may be taking action only for this exact version of the VB6 executable. If other editions of VB6 or various service packs changed this EXE I'm not sure if this will have an effect or not.
The info above pertains to VB6 with SP6 which is labelled "Version 9782" in Help > About.
Note: this did appear to work.
Recently our Development user group (Windows) has started showing with a Red Cross in Team Explorer and we cannot expand it anymore.
I have tried removing and re-adding the group but to no avail.
Does anyone know why it would display like this?
We are using TFS 2010 with VS2010 SP1 and August's Power Toys.!
BTW, "Technical Testing Team" is another Windows Domain User Group, just like Development and that works OK.
In general, the red crosses on particular services are caused either by that service being unavailable or by permissions issues...
Are you still able to perform actions that require admin permissions? Does this apply to a single project or all?
How are you defining your developers? A windows domain group? If so, is the TFS server able to see the DC?
I'd suggest you try installing Team Explorer on the TFS server and running it when logged on as yourself - see if you have the same problem. If not, it may be network or firewall problems between your dev machine and the server. At least it would narrow the problem down.
Edit 1:
Do reports work properly? (Specifically, do the graphs show up in reports)?
What auth are you using? Kerberos?
What account is TFS running as? What permissions (if any) does that account have on the network?
Can you see the security information you'd expect in the TFS_Configuration database? (Try tbl_SecurityAccessControlEntry) [Usual "Change nothing, do it at your own risk" disclaimer]
Edit 2:
As per the install docs, the TFS service should be running under its own account (IIRC they suggest Domain\TFS.Service). Check the permissions on the windows services on the TFS Server and see who they're running as. Makes sure the permissions for that user are correct as per the installation instructions
NTLM can cause problems as it doesn't allow credentials to be delegated/relayed the way Kerberos does (and has some picky setup requirements) - but that's obviously not why it's broken all of a sudden (and that usually manifests as graphs not displaying in reports).
WRT: the SecurityAccessControlEntry table, I was more interested in making sure there were entries and that it could be read properly than the contents.
I assume you've tried deleting/recreating groups - If not, give it a shot (deleting the domain group may be an issue with other services but try using a different (new) group and removing the old one from TFS entirely)
I have to admit I'm running out of ideas after that. If it were me, I'd try a clean install on a new server/VM and either point the new install at the old data store [multiple server setup] or export/import projects [single server setup].
For Multiple server setups, this would determine if it's a TFS installation issue/data corruption. For single-server, there's a good chance this would just clean up the problem. You could, of course, also ex/import on multi-server too if it does turn out to be a data thing.
You may want to hang on to see if someone has a less drastic solution.
Looking in the General tab of the VS Output windows there is a message:
Skipping loading group Development into Team Members because it has 102 members.
Looks like VS has a limit on here.
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.