I'm trying to import a site into a new VM. This vm only has the demo corporate site.
I get an error when click Import Site or Object. The event log has two entries.
Both have the following statement: Message: Access to the path 'C:\inetpub\wwwroot\Kentico9\CMS\App_Data\Persistent\import_315c65f4-dc91-4175-a4e5-fdad1601727d_settings.dat' is denied.
I check permissions in to the Kentio9 VM and they match my DEV which doesn't have this issue. I didn't set up DEV, but i can't see why my new QA VM, which seems to have the same folder permissions doesn't work.
We have a service level account for connecting to the DB, all through the application pool. Could there be something on the account settings?
What kind of Identity is the Application pool are you using for this site? What about if you set it to ApplicationPoolIdentity and then grant permissions to IIS_IUSRS for your Kentico root folder?
Additionally you can try checking the disk permissions problems documentation page.
Related
After a successful build using a hosted VS2017 agent, I'm trying to deploy on-prem using an local hosted agent which was setup using a domain account which should have sufficient permissions as it is in the local admin group. As I was digging around on this issue elsewhere, one user re-installed their agent using NTATHORITY\SYSTEM and it worked.
I d'ont really need to create or stop\start the website, just deploy the recent build artifact.
What permissions should I check or should I use another task?
019-04-06T21:03:10.3898646Z ERROR ( message:Configuration error
2019-04-06T21:03:10.3899503Z
2019-04-06T21:03:10.3899791Z Filename: redirection.config
2019-04-06T21:03:10.3900026Z 2019-04-06T21:03:10.3900293Z Line
Number: 0 2019-04-06T21:03:10.3900530Z 2019-04-06T21:03:10.3900852Z
Description: Cannot read configuration file due to insufficient
permissions 2019-04-06T21:03:10.3901076Z 2019-04-06T21:03:10.3901333Z
. ) 2019-04-06T21:03:10.8135484Z ##[error]Process 'appcmd.exe' exited
with code '5'.
An agent is running under a user. The error means that your user doesn't have permissions to read/modify the redirection.config file that is necessary to manage IIS.
You have multiple options to solve this.
Change the user were the agent is running under. In example: NTATHORITY\SYSTEM
Give permissions to the user were your agent is running under to the folder C:\Windows\System32\inetsrv\config. If you want to create app pools or websites etc, modify permissions are of course needed.
When we install Azure agent as a service(In Windows, search for 'Services' and look for something like Azure Pipelines Agent..), by default it is logged on as 'Network Service'. Change it to 'Local System' and the pipeline should be able to run IIS related tasks/commands.
I am trying to create a Group Managed Service Account. So we have promoted our Windows Server 2016 VM to Domain Controller. The object version of the schema is 87. Now I am trying to create a KdsRootKey that's giving me an error that "The request is not supported". I have logged in as a domain administrator.Please help.
If you are using Azure ADDS then you don't need to create a KDS root key as it is pre-created on Azure AD Domain Services Managed domain. Also, you can't view the KDS root key on the managed domain either. So, you can try to just create the GMSA account. If the root key doesn't exist it should fail.
I have 2 sites. Each site has one SCVMM configured to do Azure Site Recovery
ASR is configured to replicate the VM form one site to another.
Here is the issue, my VM size is big and i want to do the initial replication offline instead of over the Network and it just not allowing me saying permission issues.
Can anyone help me to find, what could be going wrong here?
ERROR MESSAGE
Permissions couldn't be set for one or more hosts on the initial replication folder path.
Provider error code: 31218
Provider error message:
The VMM service couldn't provide permissions for cs\nimbl[enter image description here][1]ecs1$ on \\nimblecs1\f$. Error: Object reference not set to an instance of an object.. During cloud configuration, the VMM service provides permissions for Hyper-V service accounts on the import and export paths used for initial replication.
Provider error possible causes:
The VMM service doesn't have the required privileges to modify the permissions on the import and export paths.
Provider error recommended action:
Ensure that the VMM service account has the required privileges to perform this operation.
POSSIBLE CAUSES
Verify that the initial replication path exists and is accessible.
I'm interested in load balancing 2+ Windows VMs in Azure. My primary requirement, though, is that an 'uploads' folder would need to be consistent between each VM. Files in this folder are FTPed by our admin users, and they would then need to select these files in a C# MVC Web app. As you may connect through FTP to one VM, but a Web connection might be to another, the uploads have to be centralised.
It looked as if the new Azure Files, currently in Preview, would help, in that they let me set up a shared drive that each of the VMs could access. My thought was that FileZilla Server would allow FTPing up to this shared 'drive', and the Web app would access it to show the contents.
I've signed up to the Azure Files Preview, and set up the share, persistently mapping it to Drive Z for the sake of experimentation. I've also created a new user and made sure they too have persistent mapping to this same drive as Z.
But I can't seem to do anything with this outside of the Remote Desktop. FileZilla, despite having its Service set to log on using this new account, won't show the contents of this drive, or write anything to it. Likewise my Web App isn't able to access the file contents, despite switching Passthrough Authentication to this new account for the virtual folder.
Does anyone know any way of accessing this drive either through the network path or drive letter? Is this just not possible with Azure Files as they are? Are there any other solutions to sharing some blobs across VMs, but treating it as a local drive or network share?
[UPDATE]
This might help. Having set up the share, and used cmdkey and net use while in a cmd prompt runas a specially created user (as suggested in http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/27/persisting-connections-to-microsoft-azure-files.aspx), if I point a virtual folder in IIS to this share, using the specific account created, and Test Connection, I get:
Test: Authentication (green tick; "The specified user credentials are valid")
Test: Authorization (red cross; "The path does not exist or environment variables in the path could not be expanded to verify whether it exists.")
While still in a runas cmd prompt, I can access the share, so it's not a specific permissions issue. It just seems to be that IIS cannot use that user to access the share, for some reason. The limitation of Azure Files is that I cannot specifically grant any kinds of permissions on the folder within that share.
What worked for me is the following:
Create a new account
Set the IIS App Pool Identity to a this specific user
Set the IIS App Pool Load User Profile property to true
start a cmd promt as this user (runas)
do cmdkey and net use (with /persistent:true switch), as you described
create IIS Virtual Diretory with physical path set to UNC share path (not the mapped drive)
A little PowerShell snippet for point 5:
$share = "your-storage-account.file.core.windows.net\yoursharename"
$usr = "your-storage-account"
$key = "your-storage-key"
#store credentials for the network share - must be done for the user that will run the app pool
cmdkey /add:subclub.file.core.windows.net\images /user:$usr /pass:$key
net use z: "\\$share" /user:$usr $key /persistent:yes
The answers here proved helpful.
Setup
Create a new user {appuser}
Open a command windows as the user
runas /user:{appuser} cmd.exe
In the new {appuser} cmd window use
cmdkey /add:{storage-account}.file.core.windows.net
/user:{storage-account} /pass:{account-key}
Set the IIS Application pool to use {appuser}
4b. Set LoadUserProfile to true
Notice no need for the net use. Don't need the mapped drive.
Code
Now here's the key piece. From your app you must write to the UNC path.
\{storage-account}.file.core.windows.net\
ex.
File.WriteAllText("\\\\{storage-account}.file.core.windows.net\\share\test.txt", "contents goes here");
I am trying to get the IIS logs to the database. Followed the steps as given in this website http://blog.datacenterfromhell.net/2013/08/how-to-write-iis-logs-to-database-using.html
It doesn't seem to work, got an error in Windows event log..
EventID: 1016
Error: The World Wide Web Publishing Service (WWW Service) did not configure logging for site 1. The data field contains the error number.
Environment:
OS - Windows 7
DB - SQL Server 2008 R2 Express edition
Please help if you have encountered same error previously.
Thanks, Naveen
Steps added:
Step 1: Create DB
Create an empty database on any Microsoft SQL server. Make sure that the identity that used for the Application Pool which is serving the Web Site has write access to this database.
Step 2: Create a table using logtemp.sql script
In C:\Windows\System32\inetsrv\ you will find a script called logtemp.sql, use it to create a table in the database you just created.
Step 3: Create System DSN on the web server that points to the
Create a System DSN on the web server that points to the DB created in step 1.
I would recommend to use the identity of the IIS Application Pool to configure the ODBC connection, since this account will later also write the log data to the database. Let's call our DSN IISLoggingDSN.
In this post I explained how to create a System DSN.
Step 4: List ODBCLogging settings
Open elevated cmd and change directory to C:\Windows\System32\inetsrv>
To get a list of all ODBCLogging settings configured so far, run this command.
C:\Windows\System32\inetsrv> appcmd list config -section:ODBCLogging
This should be empty.
Step 5: Set the ODBCLogging settings
To setup a ODBCLogging connection, issue the following command:
appcmd set config -section:ODBCLogging -datasource:IISLoggingDSN -tableName:InternetLog -username:DOMAIN\IISLogsUser -password:P#SSwoRD$
Let me explain the switches:
-section: SectionName we want to configure
-datasource: the name of the DSN we configured in step 3.
-tableName: name of the table in the database
-username: Active Directory domain account that has permissions to write to the database
-password: password of this user, it will be stored encrypted in the config file
Step 6: Enable ODBCLogging for one web site
To enable the logging for a web site, run this command.
C:\Windows\System32\inetsrv> appcmd set sites "Default Web Site" -logFile.logFormat:Custom -logFile.customLogPluginClsid:{FF16065B-DE82-11CF-BC0A-00AA006111E0}
IMPORTANT: The customLogPluginClsid attribute must be set to "{FF16065B-DE82-11CF-BC0A-00AA006111E0}"
This ID I took from the Microsoft documentation. It defines that the custom format is ODBCLogging.
Let me declutter these switches as well:
-sites: the site that will write to the logs, I tested with "Default Web Site"
-logFile.logFormat: by configuring Custom we configure that custom format will be used
-logFile.customLogPluginClsid:{FF16065B-DE82-11CF-BC0A-00AA006111E0}: see above
Naveen, did you meet all prerequisites?
The IIS Web Site which should write its log to a database must be served by an Application Pool that is using an AD Domain account identity to run.
The same AD Domain account must have RW access to the DB that will be target for the IIS logs.
ODBC AND Custom Logging must be installed on the IIS server
I wrote this blog post some months ago. You may also reach out to me via the comments of the blog.