I built an API in .Net Core that integrates with different printers through winspool, when running on visual studio, it works just fine, but when I publish it to the IIS on my local computer it doesn't work. I've read a lot and there are some local users on IIS among them the Local System user that has extensive privileges but it doesn't work, I tried that user on in the application pool that my api is using but no luck, I also tried enabling Impersonation using my user in the computer but nothing works, so I think I have to modify permissions to this IIS users, how can achieve this?
Thanks for your help in advance.
Related
As a local developer I'd like to be able to publish a site (via WebDeploy) from Visual Studio 2013 to an IIS (localhost) without starting Visual Studio with admin rights.
Is this possible and if so how?
I tried to Edit Permissions... for the site and give my account Modify rights but it doesn't seem to work... or I need to set something else too.
I did some more experimenting and tested also FTP-Deploy (ftps). It works without admin rights but it has a drawback. It's really really slow (localhost!) so I consider it as a last resort. I don't even want to think how long it runs when the site grows...
It doesn't work without running as administrator (or with elevated privileges).
The reason is that you need elevated privileges to the C:\inetpub\ folder, which is the default folder for IIS. You could (you shouldn't) disable UAC which is the original of this 'problem', but that is a workaround, and not a real solution.
I think creating a new website in IIS that points to another folder (one that isn't protected by UAC) solves the issue for you.
Another work around is to create a share to the c:\inetpub\wwwroot dir (give yourself read/write permissions) and publish to the share like so: \\mypc\wwwroot\mywebsite. It helped me get around the annoying UAC security without disabling it.
I have successfully captured an image using sysprep and can provision new machines from it, however all the custom user settings are missing (desktop shortcuts, chrome bookmarks etc...).
A more serious issue is that one of the applications I had installed fails on the provisioned machine unless run as administrator (due to the way it writes some files when being installed originally).
How can I ensure this profile information is preserved and I don't hit the permissions issue for the application?
I have been pointed at the following link (http://theitbros.com/sysprep-xp-sp3-copy-administrator-profile/) but it seems to be Win XP specific.
Profile information can be migrated to a new deployment using the User State Migration Tool (USMT). USMT is a free tool designed to help IT Professionals migrate files and settings to Windows 7 or Windows 8. USMT captures user accounts, user files, operating system settings, and applications settings and then migrates them to the new Windows installation. The TechNet articles ‘Step-by-Step: Basic Windows Migration using USMT for IT Professionals’ and ‘User State Migration Tool 4.0 User’s Guide’ are good places to start learning how to use USMT.
For your application issue, I would recommend using the Microsoft Deployment Toolkit (MDT) for your deployments. MDT can deploy your image and then install device drivers and applications to the machine automatically. These two video walkthroughs are specific to migrating from Windows XP to Windows 7 with MDT, and using USMT to migrate the user files and settings:
Part 1: Building the Deployment Environment
Part 2: Initiating the Install and Migrating the PC
There is also a Microsoft Virtual Academy 7 part course titled ‘Migrating from Windows XP to Windows 7’ that has two parts dedicated to using USMT to transfer user data and one part for MDT.
MDT can be downloaded here, and USMT is a part of the ADK which is a component of MDT.
Hope this helps,
The answer here wasn't very elegant (in my mind at least) but here is what I did to achieve the desired result:
Create the VM as usual (specifying the admin user during setup)
Create a new (non-admin) user and give them RDP access
Log in as the non-admin user
Install all the necessary software
Log in as the admin user, change the permissions for any files that were causing an issue to be readable by the non-admin user
Run sysprep as the admin and complete the process as detailed elsewhere
This gave me an image that I was able to provision VMs from. When creating the VM I specified the admin user to be created (but then never needed to login as the admin, as I would just login as my non-admin user that was created before). All profile settings for the non-admin user are preserved.
Hope this helps anyone else facing the same issue.
It is a first time I am setting up server, so sorry for stupid questions.
I am trying to setup IIS on Windows 2008. Turning off Enhanced Security Configuration allowing me to go to default site, but only for me. Other user still can’t go there. What do I need to create and how to set it up, so anybody who get to the server, will have the same internet settings?
Thank you.
Sounds like you need to give anon permission to the site try this: http://technet.microsoft.com/en-us/library/cc770966(v=ws.10).aspx
To get Windows users to log on as regular users instead of admin, I need to check that all their applications run OK with limited rights.
Is there an application specifically aimed at checking that an application can run with limited rights, or is SysInternals' Process Monitor what everyone uses for this purpose?
Thank you.
Create a test account that has the permissions as the domain users of your application Login in as this user on a non-development computer. Preferrably a computer with a new operating system installation and all of the other "standard" company software. Install the software and run. This is the only way to really test your application.
Make sure you exercise the entire application.
Make sure install and uninstall work as expected and do not leave any artifacts behind.
Having the ability to restore the operating-system and software on the test computer to its original state is a great help.
Use the Permission Calculator Tool to make sure you handle obvious issues before performing this test.
I'm not sure if it would help since I never used it but I know there's a Permission Calculator Tool (Permcalc.exe) at http://msdn.microsoft.com/en-us/library/ms165077%28VS.80%29.aspx.
Permission Calculator Tool
(Permcalc.exe)
The Minimum Grant Set Determination
tool (Permcalc.exe) is used to
estimate the permissions callers must
be granted to access the public entry
points of an assembly. This tool is
new in the .NET Framework version 2.0.
It is intended for use by advanced
users.
Run this application on Windows 7/Vista with access control enabled. You may consider Windows 7 as such testing application :)
It is recommended to use non-administrator account with activated access control on a developer computer, when you write and debug the program. This creates some problems, and Windows developers hate this, turning off access control or using administrator account. However, working on Linux/Unix, we don't have administrator rights, and this is OK.
I have two machines in two different domains. On both I have VS 2005 installed. I want remote debug between them. Without authentication it is possible but I want to debug managed code. I don't want to debug directly since it is really crappy machine.
When I try to attach with debugger I get message "The trust relationship between this workstation and primary domain failed." Any idea how to overcome this ? I tried tricks with adding same local username on both machines but with no luck.
EDIT: I have same local users on both machines. I started both VS2005 and Debugging monitor with RunAs using local users. I turned Windows Auditing on debug machine and I see that local user from VS2005 machine is trying to logon. But he fails with error 0xC000018D (ERROR_TRUSTED_RELATIONSHIP_FAILURE)
Gregg Miskely has a blog post on this. You might get it to work if both local accounts have the same user name and password. You might also try dropping your good box from it's domain so that you are going from a workgroup to a domain rather than domain to domain.
I seem to remember that I have sometimes found it useful to use RunAs when you run msvcmon (or whatever it's called this week - the remote debugging stub anyway), to force it to start as the user which you have set up to be the same on both machines.
I would guess that on the machine you're running VS on, you will also need to log in as the local user rather than a domain user (or start VS with RunAs).
I have never understood why this needed to be so hard, given that unmanaged debugging is so much easier, and must expose every security hole that managed debugging could.
The blog post wasn't totally clear that this would work, but I was able to run Visual Studio as my domain account and still debug a process on a machine that was not on a domain.
I have a physical development machine PHYSICAL on a Active Directory domain DOMAIN. I'm logged in and running Visual Studio as DOMAIN\employee.
I have a virtual machine VIRTUAL that is not attached to an Active Directory domain at all. This is the machine running the process I want to debug.
Like the blog post says, create local accounts PHYSICAL\employee (on PHYSICAL) and VIRTUAL\employee (on VIRTUAL). They both must be Administrators and have the same password as DOMAIN\employee.
The remote debugger and the process to debug must be run on VIRTUAL while logged in as VIRTUAL\employee. Then on PHYSICAL while logged in as DOMAIN\employee I can use "Attach to Process..." and connect to VIRTUAL to get a process list.