I upgraded to Windows 8 RTM a few weeks ago and yesterday I attempted to create a Windows Store account using my bizspark token. I get the message: "We don't recognize the computer you're using".
This is the same computer I've been using.. As I understand it I was supposed to get an email to confirm this as a new trusted computer when I upgraded. I never did. I have valid emails accounts and a phone number associated with my windows Live account.
In trying to figure it out I "deleted" the listed trusted computers, so that will happen in 30 days but if I click the Cancel the deletion I am taken to a screen that says:
"Use your existing security info to help us make sure this is you. How can we contact you? ", with the only option available being "Use my trusted PC".
I saw somewhere in some forum that Windows Essentials is supposed to help, I downloaded it and ran wlstartup.exe and if I remember correctly I had the option to make this a trusted PC. It made no difference, I'm still not trusted . If I rerun wlstartup it just gives me a dialog that says "Connect your favorite Services" with a Linked In logo. I tried it with no other apps running and logged out of Live and messenger. The file version of wlstartup is: 16.4.3503.728
I've tried devices.live.com , click the "add this computer" link and it takes me to the Essentials download page, which, as mentioned, I've already downloaded and ran.
So basically, I need to make my computer trusted ( again ) so I can get a Windows Store account, and have no idea how.
Anyone else have this problem?
Thansk,
Craig
Did you maybe reinstall windows 8. You need to trust the new PC from the old install, which is impossible, so frustratingly you have to wait 30 days before you can delete the old install and add the new trusted PC.
http://www.windowsitpro.com/article/security/windows-live-trusted-computer-143668
Related
This is my first time trying to deploy a VSTO add-in to a user's system, and I am running into a security barrier. The add-in was built in Visual Studio 2019 Community Edition and is meant to integrate with Microsoft Excel. The user runs Office 365.
On running Setup.exe, user receives the initial confirmation prompt and clicks "Install." A progress bar briefly appears and runs about 25% of the way, then an error message pops up: "Customized functionality in this application will not work because the certificate used to sign the deployment manifest for [the add-in] or its location is not trusted."
I understand that Microsoft would like me to pay for a signing certificate, but I am hoping to get this to work while avoiding that expense.
This article from Microsoft describes the use of a digital certificate as "an optional step": ClickOnce and Authenticode. This article states that an alternative route is for the user to click the "ClickOnce trust prompt" during installation: Grant trust to Office solutions. But as far as I understand the process, it is halted before it even gets to the ClickOnce trust prompt, so the user never gets that option.
For comparison, the user ran the installation on an older system. On that system he received the ClickOnce prompt, approved the software, and the installation ran successfully to the end. This indicates very strongly that the problem on the newer system is a security setting.
I instructed the user to open Excel and go to Options > Trust Center > Trust Center Settings > Add-Ins and remove the check mark from "Require Application Add-Ins to be signed by Trusted Publisher." There was no check mark to begin with, so that setting was not the issue.
I have instructed the user to go to the command prompt and clean out any remnants of the failed install with rundll32 dfshim CleanOnlineAppCache before each new installation attempt.
I'm at a loss as to where to look next. Any help would be much appreciated.
One relatively easy workaround: you pack the "publish" folder as ZIP file, disable any online checks or deployments (in the project settings, select to publish locally, not to a website. Installing from a website or auto-update won't work without normal certificate). Then give your user that ZIP. User downloads that ZIP, then right-click the ZIP file and checks "Unblock". Then unzips and installs normally. Now any certificate should do. This applies if your user downloads your file from the internet.
So the idea is very simple: Just tell your user to click "Unblock" checkbox before extracting files from the ZIP archive you have sent and running them.
Another solution, you simply tell the user's system to trust your "self-signed" developer's certificate (add your certificate to "Trusted Publishers" store on the user computer). For that you need admin rights. Please note that user's admins probably won't like this idea, unless you and your user work in the same organization. Here are the instructions: https://learn.microsoft.com/en-us/skype-sdk/sdn/articles/installing-the-trusted-root-certificate
The best and easiest of course would be if you buy a normal code signing certificate. They are not that expensive, you can get one from COMODO (SectiGo) for example for something like $70/year though their resellers.
On the target machine. you need to install and trust the certificate used to sign your addin (see Signing tab of your project options)
What is required for the certification process, is it a quick process? Are they certifying me/ my business or the code??
It is a quick process for the process:
Sign with valid certificate when publishing.
Add the publisher into Trusted Publisher before installing when Macro Settings is a high security level.
Finish installing.
You can obtain a certificate for code signing in one of three ways:
Purchase one from a certificate vendor.
Receive one from a group in your organization responsible for creating digital certificates.
Generate your own certificate with MakeCert.exe, which is included with the Windows Software Development Kit (SDK).
I build and sign an MSI (using WiX).
If I copy it to my Win8 machine, it works perfectly.
If I gmail it then download it on the Win8 machine, I get "Windows protected your PC" - "Run anyway" or "Don't run". This is my main question for which I cannot find answers: How does it know whether this came from a copy or it's downloaded.
I am investigating this because when I sign with a timestamp server, this popup (only when downloaded from gmail) is actually saying unknown publisher even though everywhere else things look couth.
Simple: It uses Alternate Data Streams (ADS), in particular an ADS called Zone.Identifier
For more info, see this.
If you are getting "Unknown Publisher", your package is likely not signed or the signature is not trusted. The verification only happens for packages downloaded from the internet, so the fact it does not prompt you otherwise is not indicative of a successful signature.
The detection of whether the package is downloaded from the internet happens via the Mark-of-the-web, which, as #JohannesKuhn pointed out, is implemented with an alternate stream named Zone.Identifier.
See this msdn blog for more information about MSI signing
one month before i installed openerp 7 all in one version in windows, i have successfully installed the apps when i have user less then 3 but when i create more users and try to install more app openerp account ask for email and password after that he display following message (An OpenERP Enterprise subscription is required for one-click installation of OpenERP Apps for more than 3 users.)
how to fix this issue please guide me,
i also delete all the user except administrator but same message is displayed. even i deleted the database and restore another database and try to install app but same message is displayed with old database name and same number of users
You just need to sign in with the account you used to download the installation package. The local server will then start downloading the files.
Go to the APPS section of your account to get the download.
Ideally though, you can also set up BZR to do a pull so when there are updates you can get them in relatively easily also.
Well clearly it is a bug in OpenERP v7.
I have created a bug report https://bugs.launchpad.net/openobject-addons/+bug/1260377 fell free to subscribe to it.
I installed Microsoft SharePoint and Project PWA on Windows Server 2008 R2.
When I want to open Library in Windows Explorer, I randomly get an error:
Your client does not support opening this list with Windows Explorer
When I open IE it's working for 1st and 2nd time, but after some clicks it's not working anymore and I need to restart IE and then it normally works for couple of times.
When it not working through Sharepoint it also not works via \server\DavWWWRoot\PWA and oposite.
I'm searching through the web for weeks and didn't find any solution.
Do you have any idea what should be wrong here. Any suggestion is welcome :)
I had the same exact issue with Windows 7 and explorer view. The following steps resolved the issue for me:
First - be sure that the Web Client service is running (run>services.msc).
Next - In I.E. check Tools>Internet Options>Security>Local Intranet>Sites>Advanced and add the site that you want to use explorer view with.
This finally fixed it for me. I hope that you have already found a solution to this issue! I was surprised at how difficult it was to find a solution to this problem!
This error message is a symptom to a billion different problems.
I solved this problem when I realized my XP32 box could do this just fine with IE8. So I reverted to IE8 in 7x64 (you have to do it by uninstalling updates for IE until you're back at 8) and it didn't work. The build versions were different and on the 7x64 "about" box it said IE8 was using 256-bit cipher while in XP32 it had 128-bit. That to me was a hint that there may be 64-bit issues even when you run the 32-bit executable.
Then I found this hotfix so I reinstalled the windows update for IE10 and then installed this hotfix. Now I'm able to open the TeamCenter site in question in windows Explorer. IE10 reports it's version 10.0.9200.16686. I cannot guarantee that it was the hotfix alone (and not also the reinstallation of IE10) which fixed it. But I'm willing to bet it was the hotfix alone.
In XP I found it impossible to then map this network location to a drive letter, as mapping doesn't like URL's. However in Windows 7 you can transform the URL so that it is interpreted as a Windows share. If the URL of a given folder is of this form:
https://somesharepoint.com/folder1/folder2/folder3
you can also access it as
\\somesharepoint.com#SSL\DavWWWRoot\folder1\folder2\folder3
and, in this form, it can be mapped to a drive letter.
I do have issues at that point that even with IE10 open and logged in to the site I see some random time-out like problems and I get kicked off (and prompted to log in again in IE10). My situation is complicated because the site I'm accessing requires an Exostar token to log in, so I have to log in via website no matter what.
If it helps any one do the steps suggested above:
Make sure to use 32 bit internet explorer (program files (x86)/internet explorer).
Like was mentioned above Web client must be started.
You may also need to add your site to trusted sites in internet explorer.
Make sure enabled protected mode in internet options is disabled.
This is what finally fixed it for me: Check "Keep me signed in" on the login page. This was the key for me. Will not work without it checked in my case.
I had the same symptoms, and it turned out I don't have a root site collection. Creating one solved this for me.
Summarized the troubleshooting steps here:
http://letitknow.wordpress.com/2012/07/22/your-client-does-not-support-opening-this-list-with-windows-explorer-error/
There can be multiple reasons for it.
One could be using IE x64 version. It won't work there.
Secondly, check out this blog:
http://blogs.technet.com/b/asiasupp/archive/2011/06/13/error-message-quot-your-client-does-not-support-opening-this-list-with-windows-explorer-quot-when-you-try-to-quot-open-with-explorer-quot-on-a-sharepoint-document-library-in-office-365-site.aspx
I experienced the same problem as well.
And I found out that if none of the above options are working, and if you work in an organisation, maybe the proxy is blocking the "Open with Explorer" option.
I did the same, and removed the proxy and it worked just fine.
this fixed it for me ( however in windows server 2008 you may need to install desktop experience i think its called)
After you log into windows go into services then restart the WebClient then see if you can use explorer view without the error " your client does not support. blah blah blah" if it does work then. make a batch file that says:
net stop webclient
net start webclient
then make a scheduled tasks that runs that batch file at start up. Have it run as a user with administrative rights, make sure you tell it to run even if user is not logged in. it should prompt you for the password of the admin account you selected. this worked for me with windows 7.
I found online where the error can occur intermittently with SharePoint 2010, however I think the SharePoint version is irrelevant. They said the client polls for a SharePoint root site and that the error occurs if one isn't found.
We have not seen the error since I created a root site even though we’re only using WSS3. Our errors began when we changed clients to Windows 7. So in our case it sounds like the issue could be the root site polling due to an IE8 security change in Windows 7.
SOLUTION:
*you on x64 bit machine* so solution is that there is no problem but you are using the wrong IE shortcut.
There are different IE types you can use (just type Internet Explorer in start search bar) and you will see..
Internet Explorer (64-bit) - won't show any sharepoint add-ons
Internet Explorer (No Add-ons) - won't show any sharepoint add-ons
Internet Explorer - only this will show sharepoint add-ons and will
work so basically make sure you always use this version of IE
We have a production web application that uses Windows Live ID as its authentication mechanism. For several months now, it has been working great. However, in early August, we suddenly started experiencing a serious problem...
If the user is already signed into Windows Live (via our app in another window, or a different Windows Live app) and navigates to our site, a continue button appears. It says "You're already signed in", and lets the user click Continue and be redirected to our site. In early August, this continue button stopped working. You click it and it does nothing. We didn't change anything in our code, and lo and behold we're not the only ones experiencing this problem: http://social.msdn.microsoft.com/Forums/en-US/wliddev/thread/15405d0d-8c14-4e10-821b-55c3bae580bc
It's clearly a bug in Microsoft's page. What we need is a workaround - our customers quite literally can't get to our app if they are already signed into Windows Live. They have to go to a different website, sign out and then go back to ours. You can imagine that this is a pain, and makes us think twice about using Windows Live as an auth mechanism.
Pending Microsoft's bugfix, we are dead in the water and having to explain this to customers. We are looking for workarounds and working on our own.. our current solution is, 'Make sure you're not signed into Windows Live when you go to our web app.' Less than ideal. Any ideas?
Thanks!
This has been fixed by Microsoft.