So this morning(05-09-2022) i plugged in my external hard disk as usually, i use this hard disk every day, but i got an error message stating access denied. A warning popped up from crowdstrike stating functions of your usb device are restricted by your organization's policy.
few points :
I don't work for any organization.
I heard about this software for the first time today and checked in control panel that it was installed last month on 23-08-2022. I have no idea how. I checked my event logs and found this.
Product: CrowdStrike Sensor Platform -- Installation completed successfully.
in MsiInstaller.
This software requires a key to be installed.
How did this software enter my system in the first place and how do i uninstall it?
NOTE : I did use this system for some office work but that was 2 years ago and all the software installed by that organization were uninstalled.
Related
This has been asked before, but I've been through all the answers provided elsewhere so far, i.e. checking permissions on c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, adjusting protocols using IISCrypto and turning use of FIPS algorithms on (and off) and I'm still getting batches of 4 events every 10 seconds which swamps the System event log.
I'm running Windows Insider Preview 10 Build 19592.rs_prerelease.200321-1719 (64-bit) so this could be a preview specific issue, however, is there anything else I can try to correct this error?
same issues here, same error code, same pattern , same windows build, tried ISS CRYPTO BEST PRACTICES fix attempt. Did not resolve.
This is not a server, its a standalone client in a home network with no other computers active. Office is not installed, no Exchange, no IIS, no server applications of any kind, just stock windows services. Install is fresh.
Active Browser is Chrome Portable with some basic security plugins such as UBLOCK,Tampermonkey and Adblock. The only webpage opened is this one.
The answer I finally got from a comment on anothersite was that this was a known issue in the Insider Preview and it's now been fixed in the latest releases.
I've gotten this error on an ASP.NET Core 6.0 service that used to work fine previously. The problem turned out to be faulty deployment, that removed all files from the virtual directory.
At a client of mine, in-house applications are all located on a network share. Users create shortcuts to the required applications from the network share so we can easily make sure everyone uses the latest version.
This works fairly well, although we often have an issue when users are still using applications when we'd like to release a new version. For most applications, we'd forcibly remove all the file locks on the server and release the new version. Not a very elegant solution, especially since we need assistance from another department for this.
For newer applications, I've developed a cleaner solution, where the application intermittently checks if it's still the most recent release. If it isn't, it shows a message to the user, asking him to quit the application at first convenience, or within 3 minutes. After 3 minutes, the application quits itself and all is well. However, some users will immediately try to re-start the application. The application will then show a simple MessageBox telling the user this version is currently not supported. My problem is this: while this MessageBox is visible, my executable is still locked.
I'm looking for any of the following solutions:
Releasing all locks on the current assembly files from within code
Showing a message box that lingers after the current assembly has exited
This is exactly precisely the problem that .NET ClickOnce deployment is meant to solve. Users have a shortcut they can click, the latest version is downloaded on application start, and there are no server-side executables to be locked if a user leaves their process open.
ClickOnce Deployment Overview
HowTo:Publish a ClickOnce Application
We have developed a software in vb.net using Visual Studio 2013. Now we want to build a custom installer with following steps/features:
User Start to install our software.
At 'Enter Serial Key' option, user enters the 16 digit Serial which have we provided.
When clicking 'OK' button, our software connect to our IP and save the Serial Key with some other user's information to our database.
A confirmation Key is returned back to our software.
Software writes a file and save it to the system folder.
It is almost like Adobe or Corel registration process.
We are open to other techniques also which must secure that our software must install on a single machine only.
Please be noted that we are a group of novice programmers(not so advance level), so; if the process is elaborated, it will be very helpful to us.
One-Shot Setups: "A setup is run once, an application can be started again - in order to resolve and debug problems interactively - with meaningful error messages show to the user."
Hence: avoid license validation in the setup.
Short version on licensing.
License Key: Preferring to deal with license keys in your application seems logical for several reasons: the one-shot nature of setups
yields poor reliability (no interactive debugging - poor ability
to resolve problems). The end result is lots of support calls for something very trivial.
Further, the risk of piracy and hacking is a major concern when
exposing a license validation DLL in the setup. And finally
communication over the Internet is difficult with today's setups (proxies, firewalls, etc...) - which is a modern way to validate license
keys (in the future setups might have full Internet access, but be careful assuming too much since corporate users may have lots of restrictions and poor deployment could hurt sales and acceptance of the software for corporate use).
Finally your application must usually support a trial version,
and then you need a license dialog in your application anyway.
Why complicate your setup too?
CAs: Custom actions are complex and vulnerable to failure in general - due to complex sequencing-, conditioning- and
impersonation issues and overall poor debugability. More information:
Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Overall Complexity of Deployment: A short, attempted summary of the overall complexity of deployment:
Windows Installer and the creation of WiX
(section "The Complexity of Deployment").
I would remove all licensing features from the setup and add them to the application. Your setup can still write a license to disk or to the registry by passing it to msiexec.exe as a public property -
UPPERCASE properties (or you can "hide" things a little more by using a transform to apply the serial property - it has exactly the same effect as setting the property on the command line). You can also set the LICENSE property from a dialog in the setup when it is run interactively, but my favorite approach is to allow adding the license key unvalidated to the registry in silent deployment mode, and to instead enter the license key directly in the application, and not the setup, for interactive deployments (the above description is for silent deployment):
msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789"
This will allow the license to be easily added to each machine in a corporate deployment scenario. The license value is simply written to disk or registry without validation. The application will verify it (more secure than a validation dll in the setup).
There is no need to mess with any complex setup dialogs, but you will need a license dialog in your application as explained below.
As a setup developer you should offer to help implement the feature in the application instead of the setup so it doesn't seem like a case of "passing the buck". This is all for overall software reliability and foolproofness - and several reasons are listed below.
Almost all large corporations deploy MSI files silently, so the setup GUI will be ignored most of the time anyway. You are then simply adding risk and wasting resources if you deal with licenses in the setup.
One drawback: An application run as a non-admin user after installation can not write to HKLM to share a serial between all users on the computer (a setup running with elevated rights can). It must either write to HKCU or the setup must have prepared write access to a specific HKLM location in the registry for the application to write to. I prefer writing to HKCU for each user since the license is then less available for copying by others, and it is kept as user specific data (allows roaming, though that is a hated feature by most IT professionals). However, a HKLM license key written by the application or the setup during installation (as explained above with a public property set) allows all users to share a license when launching the application.
There are several more concrete reasons to keep license handling and validation out of your setup:
A significant number of support requests always result from people who have problems registering their license keys in the setup. A setup is run once, an application can be started again if there are problems. This is more important than you might think for inexperienced users. You also have better features available to handle exceptions and error conditions and whatever unexpected problems may occur in the application.
Serial validation in the setup exposes a validation dll / method that is easily cracked by pirates. You won't prevent piracy by eliminating it from your setup, but at least you make it more difficult. It is more secure in the application if you cloak things a bit (static linking, encryption, obfuscation, putting the validation process online, and / or whatever is done by security professionals that I am unfamiliar with).
Allow application trial version: If the setup needs to support a trial version of the application, you should allow the user to enter a license key if they end up buying the product - preferably without having to re-run the setup or uninstall / reinstall just to add the license key. In other words you will likely need to deal with licensing in your application anyway, why complicate your setup too? More risk, more QA, more potential support requests and potential for multiple required fixes in both setup and application. High total cost?
If your application runs with different editions, what if the user buys an upgraded license? They should just be able to enter it into the license dialog and unlock features if possible and not uninstall and reinstall with all the clunk that involves. For some upgrades this is hard to achieve though, and you often end up with separate setups for different editions.
If the network is using a proxy server for Internet access, you will have problems registering the license over the Internet during the setup (often asked for by marketing). You have more features to check and deal with this in the application - it can try again and wait for access (generally you hook up to IE for automagic proxy configuration if possible). For corporate deployment you need a silent install option too which doesn't validate the key but just writes it to the registry. Trying to access the Internet from a silent install of an MSI is in my opinion a rather extreme deployment anti-pattern. I find it dubious in the setup GUI as well. Do the registration in the application - much less controversial, and you can set up firewall rules to allow it to access the Internet (msiexec.exe is likely blocked - and for good reason). There could also be hardware firewalls and / or security software to deal with that makes Internet access difficult or even impossible without some clunky admin server configuration. This could kill your software from consideration is my experience: "Just get this off our network and application estate - there must be better options - far too clunky and error prone".
UPDATE: As deployment technology matures and becomes more "Internet based" this "truth" may change, and we could end up doing everything "online" with deployment designed specifically to run via online "repositories" for example. We will have to wait and see. For now my opinion is that any setup Internet access requirements are erroneous and undesirable.
Setups that mess with licensing may sometimes cause license data to be deleted during upgrades, patching and migration scenarios due to bugs in the setup. This is a lot more serious at times than you would think - the package might hit thousands of workstations in large companies and be cumbersome to fix.
There is a rather bad "anti-pattern" in the MSI technology itself whereby self-repair or manually triggered repair will reset values in the registry that has been changed by the application. This can wipe out license keys. We see this all the time, and it is the technology's fault. It is just not logical in this area.
There are some fixes - or rather workarounds - for this (use a permanent component, write license from a custom action instead of from a component, etc...), but I find them quite clunky and you have to have a lot of experience to know all the pitfalls - and even experienced users mess this up.
Licensing is a huge corporate headache - often what is desired by a company or corporation is that licensing is centrally managed on a server, and not based on text serial numbers at all (for example concurrent or floating licenses acquired on application launch via the network). Just mentioning this though it is sort of out of scope for the question. In these cases what you specify during installation is generally an IP address pointing to the license server, or just a regular host name to be resolved by WINS or DNS.
As you might have already guessed Windows Installer doesn't provide any out the box feature to handle licencing. But there are commercial licencing solutions which you can go for if affordable.
LogicNP
DESAWARE
Since this is very broad question difficult to explain low level implementation details. I can give you a direction.
First of all you will need a custom UI where user can type in the License/Activation key. There are ways to incorporate a custom UI into windows installer, I have already explained few approaches in SO, refer to the following threads.
Show custom Form during installation
How to add additional custom window to VS setup projects UI flow
By following above approaches you should be able to add a UI where user will type in a key. Once user added the key, he will press Activate button on the custom UI, Button click event handler will invoke the necessary logic to Insert/Validate the activation key entered by the user.
Maybe you could try Inno Setup which is free (even open source) installation system.
It is script based which allows you to tune your installer and perform in it everything!
Creating custom page with entering serial number is really easy, see this example: CustomPage for Serial Number in Inno Setup
and there is also integration for Visual Studio.
I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
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