I've run into an issue that was originally exposed by Microsoft.CSharp.CSharpCodeGenerator throwing an UnauthorizedAccessException: Access to c:\Users\[wrong-user]\AppData\Local\Temp receiving an "access denied" error attempting to write into a different IIS AppPool user's temp directory.
I have another application which actually runs as the [wrong-user] AppPool, and that application does work. However, this makes sense, since it has write access to it's own user directory.
I've narrowed the error down to the fact that %USERPROFILE% is returning the path of a different IIS APPPOOL user, even though Environment.GetFolderPath(SpecialFolder.UserProfile) returns the correct path.
If I enumerate Environment.GetEnvironmentVariables(User), I get:
Path - C:\Users\[wrong-user]\AppData\Local\Microsoft\WindowsApps;
TEMP - C:\Users\[wrong-user]\AppData\Local\Temp
TMP - C:\Users\[wrong-user]\AppData\Local\Temp
Additionally, manually accessing the user's environment variables via HKEY_USERS/[SID]/Environment confirms that it is simply down to %USERPROFILE% being incorrect:
Path - %USERPROFILE%\AppData\Local\Microsoft\WindowsApps;
TEMP - %USERPROFILE%\AppData\Local\Temp
TMP - %USERPROFILE%\AppData\Local\Temp
The issue ended up being that setProfileEnvironment, which isolates the environment variables for each application pool's worker processes, was set to false on system.applicationHost/applicationPools/applicationPoolDefaults despite it having a default value of true according to the documentation. Since none of the application pools were overriding it, they all received the same value and thus shared common environment variables.
I have no idea how it got set to false, nor how the shared USERPROFILE environment variable got set to one application pool but never another, but setting the default value back to true resolved the issue.
It was this question/answer which helped me find the cause, despite the problem being different.
Related
AzureWebJobsScriptRoot variable is not defined on Azure Functions. The code below returns no value.
System.Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Process)["AzureWebJobsScriptRoot"];
However, %HOME%\site\wwwroot will be returned based on below:
AzureWebJobsScriptRoot
AzureWebJobsScriptRoot
The path to the root directory where the host.json file and function folders are located. In a function app, the default is %HOME%\site\wwwroot.
Key Sample value
AzureWebJobsScriptRoot %HOME%\site\wwwroot
It returns correct value locally, not %HOME%\site\wwwroot
Update
Is this a bug with Azure Functions?
If so, what is an alternative solution?
Before the issue is fixed by Microsoft, can this variable, AzureWebJobsScriptRoot, be defined myself to "%HOME%\site\wwwroot" on Azure?
https://github.com/Azure/Azure-Functions/issues/1146
https://github.com/MicrosoftDocs/azure-docs/issues/26761
I test in my site and get the same problem with you. As the article said, when running in Azure, will default to %HOME%\site\wwwroot and it set the function folder under home\site\wwwroot.
However, when I set AzureWebJobsScriptRoot in Azure funtion Application Settings, it will show in the output like below:
If you configure a function app with a different value for AzureWebJobsScriptRoot, then the functions host should honor that new value. For example, if you set AzureWebJobsScriptRoot = D:\home\site\wwwroot\foo then the functions host would look for a host.json file and function directories in the D:\home\site\wwwroot\foo location.
By default, this environment variable is not set. So it is expected that if you did not set it yourself, then System.Environment.GetEnvironmentVariable("AzureWebJobsScriptRoot") will return null.
Be aware that if you modify this setting, other components like the portal, visual studio, visual studio code, etc will not be aware of setting and will deploy your code to the normal default location. If you want to customize this setting, its up to you to make sure the application code is deployed to the right location.
Please refer the full details here
I have a node application and I'm trying to use the google language api. I want to set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the json file in the same directory (sibling to package.json and app.js).
I had tried process.env.GOOGLE_APPLICATION_CREDENTIALS = "./key.json"; in my app.js file (using express), but it isn't working. I have also tried putting "GOOGLE_APPLICATION_CREDENTIALS":"./key.json" in my package.json and that didn't work as well. It DOES work when I run in the terminal export GOOGLE_APPLICATION_CREDENTIALS="./key".
Here is the error message:
ERROR: Error: Unexpected error while acquiring application default credentials: Could not load the default credentials. Browse to https://developers.google.com/accounts/docs/application-default-credentials for more information.
Any tips are appreciated, thanks!
After reading and reading about this issue on the internet, the only way to resolve this issue for me was to declare the environment variable for the node execution:
GOOGLE_APPLICATION_CREDENTIALS="./key.json" node index.js
Because I was able to print the token from my server console, but when I was running the node application, the library was unable to retrieve the system environment value, but setting the variable for the execution, it was able to retrieve the value.
It could be that the environment variable in your OS was not accurately set. For example in Linux you usually have to set GOOGLE_APPLICATION_CREDENTIALS in the terminal where you executed your app.
export GOOGLE_APPLICATION_CREDENTIALS="[PATH]"
Another option you have is passing the json path by code. It is documented this process using Node.js with the Cloud Storage.
Just to update this thread.
Relative paths with GOOGLE_APPLICATION_CREDENTIALS now works fine with dotenv :)
Just store your service-account credentials as a file in your project and reference it relative to your env-file as a path. Then it should work fine :)
I encountered the same issue. I was able to get it working by doing the following:
export GOOGLE_APPLICATION_CREDENTIALS="//Users/username/projects/projectname/the.json"
The issue is covered mostly in the docs here.
the command varies slightly depending on what your OS is:
The GOOGLE_APPLICATION_DEFAULT environment variable you are setting is accessed by the google client libraries - it wont work with a relative path, you'll need to set the absolute path.
We just upgraded to Sitecore 8.1 from 7.2. Search engine is Lucene and xDB disabled. The solution is hosted in ms azure cloud services Web Apps.
We noticed that the CMS CA is quiet slow. While looking at logs noticed a number of error logged below:
13876 2015:12:18 05:21:44 ERROR Could not compute value for ComputedIndexField: _content for indexable: sitecore://web/{2E25F9D3-BBBF-4160-BAE1-1EE4E701BD9B}?lang=en&ver=1
Exception: System.UnauthorizedAccessException
Message: Access to the path 'D:\App_Data\data\mediaIndexing\b3cd2fa1-9671-498f-9534-a94ad5a21923-Mypolicy.pdf' is denied.
Source: mscorlib
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalDelete(String path, Boolean checkHost)
at System.IO.File.Delete(String path)
at Sitecore.ContentSearch.ComputedFields.MediaItemIFilterTextExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.ComputedFields.MediaItemContentExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.LuceneProvider.LuceneDocumentBuilder.AddComputedIndexFields()
Could someone please suggest why sitecore is looking for Web forms for marketing index which we don't need it?
Thanks
There is nothing about WFFM index in your error - it only says that it cannot compute value of the _content field for {2E25F9D3-BBBF-4160-BAE1-1EE4E701BD9B} item.
It even tells you the reason - cannot access path on the drive. You should check access rights for the D:\App_Data\data\mediaIndexing directory and make sure it can be access by you application user.
With Azure Web Apps you should have a full access in the file system to the webroot and its descendants. Ensure the MediaIndexingFolder setting is not set to absolute path and does not point to outside of the webroot where the application lives.
By default, if the MediaIndexingFolder setting is not specified, it points to the $(dataFolder)/mediaIndexing path, where the $(dataFolder) must point to the \App_Data under the webroot.
We recently had the same issue. Essentially, make sure that on an Azure WebApp the standard zzDataFolder.config file is used which contains:
<sc.variable name="dataFolder">
<patch:attribute name="value">D:\home\site\wwwroot\App_Data</patch:attribute>
</sc.variable>
Using the other config that is included (DataFolder.config, which sets it to "/data") or your own config file (pointing to anything other than the full drive path) will break the mediaIndexing folder path (even though all other parts of Sitecore which use App_Data like "diagnostics" or "MediaCache" work perfectly well with the "/data" setting).
I have a need to write a .NET application which will query Active Directory while running in Windows PE on a computer which is not yet a member of the domain.
We are running this during a Microsoft Deployment Toolkit task sequence (note that MDT 2012 has been configured to load support for .NET into the WinPE environment - the .NET application is starting without any problems).
I am using the code below to bind to the domain:
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
I have tried a path both of the form:
LDAP://domainServer/dc=domain,dc=name
And also without a domain controller name as
LDAP://dc=domain,dc=name
I have also tried using a username both of the form domain\username and also just username.
The DirectoryEntry object seems to be constructed okay, but when I try to execute Console.Writeline(entry.Name) to confirm a valid connection has been made, I get the following exception:
System.Runtime.InteropServices.COMException (0x80005000): Unknown
error (0x80005000) at
System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_Name()
I have tried other variations on this code, trying to execute LDAP queries with various filters, trying to rewrite it in VBScript, etc... but the code posted above is the simplest example I could come up with which reproduces the problem.
From what I have read, in a scenario like this you would always need to use AuthenticationTypes.ServerBind and that is why I am trying to specify the code within the ADSI LDAP path. But what is wrong with the code above? To me, it looks like it is passing all needed information in the parameters to the DirectoryEntry constructor.
There is a way to get it work, but it's not supported by Microsoft. This post helped me a lot. It works, tested and approved for a deployment of new computers :)
Get the ADSIxXX.inf from the zip file to C:\ADSI
Copy the following files from a Windows/System32 to C:\ADSI. Carefull of Architecture
x86 x64 -
adsldp.dll
adsmsext.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll
Mount the bootimage.wim
No need to load Package (Your WinPE is already configured to load .NET API), juste add ADSI driver:
Dism /Image:C:\Mount /Add-Driver /Driver:C:\ADSI\ADSIxXX.inf /forceunsigned
No need to load his script
Unmount the bootimage.wim
Then it's done, if your .NET application is well implement ;)
I'm not sur the PIPE | is supported as an argument too, just set to AuthenticationTypes.Secure -
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
Link: http://www.deploymentresearch.com/Research/tabid/62/EntryId/74/ADSI-plugin-for-WinPE-4-0.aspx#AddComment
I have to run command line operation from some legacy ASP application.
Here is my code:
<%
cmd = "%comspec% /c echo Hello"
set wsh = CreateObject("WScript.Shell")
ireturn = wsh.Run(cmd, 0, true)
set wsh = nothing
%>
And here is result I am receiving:
Microsoft VBScript runtime error
'800a0046'
Permission denied
/test.asp, line 6
Do you have any idea how to make IIS6 to run this code?
Note: Of course I don't have to run echo command but I want to exclude any additional causes of the problem.
Update: I tried most things tomalaks mention however nothing helped. Maybe I can alter question a little. How can I debug this problem?
ASP usually is denied access to anything potentially dangerous, such as cmd.exe. Check file permissions on cmd.exe to see if that is true for you (I suppose it is).
If you really must use cmd.exe to do part of the page processing, either change file permissions on cmd.exe (not recommended for an Internet-facing web-server), or make sure that the ASP page runs credentials that are not denied access to that file.
To achieve this, use the IIS management console to remove "anonymous access" to the ASP page and use Windows-integrated authentication instead (if feasible), or leave "anonymous access" on and enter a fixed set of credentials that should be used instead of the default "IUSR_...".
Alternatively, if you use cmd.exe just to start a program that outputs something to STDOUT, you can try starting the program directly, without wrapping it in a cmd.exe call. Again, the user the ASP page runs under needs access to that program's executable.