I've been trying out the examples provided by microsoft
SampleCredentialProvider
as a test i've compiled one of them and registered the dll. The logon screen now displays two additional tiles, "Administrator" and "Guest", Clicking on Administrator and providing a valid password allows me to login without issues,
however once I lock the screen and then do unlock, I re-enter the password but I get "Logon failure: unknown user name or bad password".
Has anyone come across such issues?
Could it be that the computers are part of domain?
Answered : I was using a beta version of the samples, always ensure you download the latest version
Changes include
• Fixing unlock. Post-Beta2, Windows Vista changed to require a KerbWorkstationUnlockLogon message type to unlock the machine and a KerbInteractiveLogon message type to log on to the machine. Previously it would accept a KerbInteractiveLogon message type for both logon and unlock. The samples have been updated accordingly. [v3.0]
Related
I'm following this tutorial: https://training-legacy.genexus.com/en/training/global/courses/smart-devices-en/introduction-to-genexus-16
and i have the Genexus 16-trial version.
In the end of the "First Transaction design" lesson, you have to send the changes to Genexus server,
but this is what happens when i open the "Team Development" page
If i enter the link in the message, from my browser https://sandbox.genexusserver.com/v16/ i can login normally, authenticating with Genexus Account and i can see my knowledge base in there.
I have pending commits, following the steps of the tutorial but i can't commit them. I wrote a commit message and pressed commit at the right bottom corner of the window and it rerturns a similar message:
error: GAM11: The user or password is incorrect.
Failed: Commit
The only 3 user and password i found were:
When creating the KB (if you disable Windows NT integrated security) but i couldn't find a valid user id and password for that, also the tutorial doesn't do this so i doubt this is it.
At tools -> Genexus Account, i can enter my email and password, and i think the IDE asks you to do this when sending the KB to the Server the first time, but when i fill it with the same credentials i use to login in to the website and press "sign in" now, it doesn't give any response.
Lastly There's the Windows Generic credential that is created but i don't even know how, just found it browsing at the genexus wiki and i have no idea what interaction it has with all this (if it does).
it is below preferences. If you do not have the view near KB explorer then you should go to the menu toolbar —> View —> Other tool windows --> preferences in order to activate it.
Team Development properties in Full Version
Note: Trial has no properties available below TeamDevelopment Tab
Team Development properties in Trial Version
Could you double check if you have the correct credentials below TeamDevelopment node?
Team Development
Locally installed TFS2013, VS2015 and VS2013 using SharePoint services.
So far the development system is kind of OK, meaning I can create a collection, create a team project within a collection, add a new solution to that, run it, do a Check In and the SharePoint site shows the project code, etc. I can also create work items at the SharePoint site and from within Visual Studio.
But I'm having difficulty understanding how the user accounts are interacting. On my development workstation I logged in with a normal domain account. But I do not see work items assigned to that user name. I only see work items if they are assigned to the system Admin account.
I would have expected VS would be operating under the user account that I logged into Win10 with, but it seems to be operating as though VS is logged in as the system Admin.
Why is that? Is there a place where VS sets data that tells TFS what user name it is operating under? And, of course, I may be asking the wrong question because I don't understand the problem, but this is how it appears.
Added after initial post for clarity
This panel shot shows where the Work Items were not showing up for the user under Available Work Items. Because of the issue identified in the answer below, only work items assigned to Admin were present. But after clearing the cached credentials the work items displayed correctly according to the proper account, no longer acting as Admin.
This may due to the VS had cached your system Admin account.
The simplest way is to delete the related credentials which stored in control panel > Credential Manager> Windows Credentials
Then reopen the VS and try to connect to TFS server. It will pops up a credential window, just type your login domain account.
I've recently upgraded from windows 7 to windows 10 and when installing GitHub desktop, I'm getting the following error:
"Application cannot be started, contact the application vendor."
When I click on details, there is the following error:
"Unable to install this application because an application with the same identity is already installed."
I tried several troubleshoots, such as:
running the .exe file as administrator;
deleting the 2.0 folder from Local/apps/
disabling windows defender
But none of them seems to work. I cant understand what the problem may be, since I had no trouble installing github desktop on windows 7.
EDIT This method solved my problem:
Hold Windows button + R
Type in %TEMP%
Delete the entire content of temp.
I fixed this problem by adding permissions to the UserName for the of the folder containing GitHub.exe:
Using the explorer paste "%UserProfile%\AppData\Local\Apps\2.0
In the search box write "github.exe"
In the result list right-click the file & select open file location.
Right click the folder -> Properties->Security
Click [Edit...] for "Group or user names:"
Add the account user name to the list giving it full permission.
This may not apply to your situation, but here is what fixed the problem for me:
Find this file:
C:\Users[YOUR USER NAME HERE]\AppData\Local\GitHub\TheLog.txt
In that file, search for this string:
"System.Security.SecurityException: Requested registry access is not allowed."
If you find that, look down from that line, one at a time, until you find mention of some specific application. For me it was MS Visual Studio:
"at GitHub.IO.ExternalProgramLauncher.IsVisualStudioInstalled()"
Running as an administrator, run regedit and look for keys related to the application in question. If access to reading them is denied, rectify that by right-clicking on the name of the key and choosing 'permissions'. (I decline to provide instructions on how to use the permissions interface here, but it is fairly straightforward) If you can grant yourself permission, that may fix your problem. It worked for me.
If you want to find the exact correct key, download and use a tool from MicroSoft called 'Process Monitor'. Unfortunately, even when you filter to show only registry events, you will still have at least 25,000 or so to look through, and the list is not sortable. >_< This was not exactly easy, but by scrolling up from the bottom and looking for 'ACCESS DENIED' in the unsortable 'Result' column for a while I was able to find the exact registry event where access was denied which caused GH DT to fail. In my case it was this key:
HKEY_CLASSES_ROOT\VisualStudio.DTE.14.0
I ran regedit using my admin account, and ran it 'as administrator', found the key and changed the permissions. Oddly, it only worked when I added 'Administrators' (plural). When I added 'Administrator', it still refused to allow access to the key.
Hope this is related to your problem, or someone's who reads this. :)
Simply right click on the installation file and run as admin. It will automatically adjust itself to your system settings and install without error.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html
I am facing a peculiar problem; I am creating a setup.exe in Installshield 2008 Primer Edition and install the setup in a laptop which has the Operating System Windows XP Professional.
The setup runs fine and install all the files successfully but when I click the Uninstall icon during Uninstallation process the below error will appear
Product: [Product Name] -- Error 1310. Error writing to file:
C:\Config.Msi\997da2c.rbf. system error 5. verify that you have access
to that directory.
Though I have surfed and got couple of answers like Unregister the msi engine and again register it that is:
msiexec /unreg
msiexec /regserver
By unregistering and reregistering the server will solve the right now; but after a couple of days the popup starts appearing again.
Some sites say the problem is that proper access rights are not given; I have cross-verified in the laptop also the user is having full control to the C:\Documents and Settings\All Users folder.
One more point I need to make: I am unable to simulate the above problem for desktop systems. How can I solve this issue?
Right click on the installer and choose "Run as Administrator"
I have faced error 1310 and I think error 1310 is one of the common error.
Click Start.
Click the arrow button next to the Shutdown option.
Select Log-Off option.
Wait till the active user account is logged-off.
Select the administrator user account, enter valid password and log-in to your computer.
Re-start the installation program.