We have an application which connects to Windows Servers via WMI to obtain configuration information. The vast majority of our servers are in a Domain and work correctly but I am having problems with two stand-alone Windows 2008 servers because of UAC. The problem is that because the servers are stand-alone I have to use Local Accounts to connect to them. I have created Local Accounts on each of the servers and I have added them to the Local Administrators Group but when connecting remotely UAC effectively removes the accounts from the Local Administrators Group. As a result, any permissions which were granted via the Local Administrators Group do not work. To get around that I have to specifically grant the various required permissions to the Local Accounts. For example, to access WMI the accounts first need access to DCOM, so to fix that problem I have added the accounts to the 'Distributed COM Users' Local Group. Next the users need access to WMI so I have created a Local Group called 'WMI Users', added the accounts to that group, and given the 'WMI Users' group full access to the WMI Namespace from Root level down. Now for the actual problem! Our application first attaches to the server via the C$ or Admin$ shares and updates WMI. The problem is that because UAC strips the Local Accounts from the Local Administrators Group when attaching remotely, the accounts do not have access to the C$ or Admin$ shares and that causes our application to fail. So ... to fix this problem I need to modify the C$ and Admin$ shares to allow access by the 'WMI Users' Local Group. So the question is ... does anyone know how to modify permissions on the C$ and Admin$ shares please? I can't add the servers to a Domain and I also can't turn UAC off unfortunately so modifying the admin shares seems to be the only solution but I cannot find any documentation which shows how to do it. If it isn't possible then I will have to pre-install the WMI components that our application needs but if I go down that path then I will have to manually keep the two servers updated from here to eternity - which I obviously want to avoid if at all possible. Thanks in advance for your time...

Hi cron22, Thanks for getting back to me... When you say the "file services snap-in" I presume that you mean the "Share and Storage Management" and, or the "Shared Folders" MMC snap-ins? Yes I can see the Admin$ and C$ Shares (and the other Admin Shares) with those snap-ins - I can see them in Computer Management too - but unfortunately it isn't possible to update the permissions using any of those utilities. The error message is "This has been shared for administrative purposes. The share permissions and file security cannot be set." One option I thought might work would be to remove the Admin$ and C$ Shares and then recreate them manually. That way they might not be recognised as Admin Shares and I might be able to control the permissions then. I'm not sure though and it's a bit ugly. I was hoping to get something a bit more 'official' - so to speak - by posting the problem here... Thanks a lot for your time - much appreciated. Thanks and Regards, Phil

Those shares are just for WMI, right? And yes, I was referring to those snap-ins. I honestly don't know if you can touch the C$ and admin$ shares to modify them. I've never had that problem because I've always just turned off UAC if it gets in my way. Why can't you turn it off though? and why can't those servers be part of the domain? I mean, if all the rest of them are joined, then why can't those two be?

Hi, You cannot change the share permissions for drives or the admin$ share as the system regulates these. Secondly, UAC only strips the administration bit from your logon token when the logon type is interactive. So, this isn't what's happening with your remote connection unless some facet of the application is using a logon type of 2 (which you can check in the Security event log). You can verify this behaviour yourself: Open a command prompt (doesn't have to be elevated)Type: net use \\x.x.x.x /user:hostname\usernameProvide the password when promptedRun: dir \\x.x.x.x\c$ Assuming the server build hasn't been hardened with firewall settings or the removal of the "File and Printer Sharing for Microsoft Networks", you will see a directory listing. You might want to do some testing with WbemTest (which will also allow you to specify the connection credentials in the Connect screen) to cross-reference whatever it is your application is attempting to do. The System (COM initialisation errors) and Application (subequent errors) event logs will also be your friend while testing. Cheers, Lain

Hi cron22, Thanks for getting back to me again - I really appreciate it... The environment I work in is unusual (to say the least!). I won't go into all the grim details but basically my job is to implement an application which goes out and interogates all of the Windows Servers - via WMI - and then feeds the data back into a Configuration Management Database (CMDB). The company has recently implemented a new CMDB and so this application I am implementing is new too. Now then ... there are a huge number of Windows Servers and quite a few Domains. It's a very big and very complex environment and it seems to me that it has grown chaotically over the years, as opposed to having been designed. If someone actually designed the environment to be the way it is then they should be shot! The end result being that there is a Windows Team who 'owns' and administers all of the Hardware and Operating Systems, then there are a huge number of business teams who 'own' and administer all of the applications. The point being that if it were up to me I would do exactly as you suggest and put the servers into one of the Domains. Stand-alone servers are a nightmare and there are a lot of them here. It's very annoying because I have to organise Local Administrator accounts on all of them and then maintain them - i.e. refresh the passwords and all that wonderful type of stuff. I am chasing the relevant teams and people in the hope that I can get the offending servers added to a Domain and if I am able to convince them to do so then that will be my solution. However past experience has taught me that my chances probably aren't great and that even if I succeed it will probably take a considerable time before it's implemeted. As an example of what things are like here, I sometimes find that a server has DCOM disabled. Either that or Remote Launch and Remote Activation have been turned off. I track down the owner and explain that I need to reconfigure DCOM to enable my applicaiton to access WMI. The type of response I then get back is often along the lines of, "well ... we don't know why the architect did that but he must have had a good reason to do it and so, no, you can't change it". That's what I'm dealing with here! Usually the architect is long gone and the design document doesn't mention anything about why DCOM was disabled so that's the end of that... Another option is, as you say, to get UAC turned off. Once again I will try but I think my chances of getting that done are virtually zero. Considering that UAC is a security feature I don't think there is any way I will get permission to turn it off on some servers. In fact ... I'm not even sure I would want to do that in an environment of this size because then they'd have to keep track of which servers had UAC turned on and which servers had it turned off. I think that would be ugly and cause problems down the track. That's just my opinion anyway... It certainly seems as if it isn't possible to update the Admin Share permissions. I was hoping that there might be some sort of Registry update or something like that. If there is a way then no one seems to know what it is! As another possible solution I have gone back to the people who wrote my application and asked them if they can give me the option to attach to a different share name - i.e. other than C$ or ADMIN$. If we could configure the application to use our own share name then I could simply create some new shares and give them the permissions I need. I'm not sure what else I can do at this stage! Thanks again for your help, Phil

Under the file services snap-in, you can see these shares I think. Click file services in Windows Server 2008 under roles, , and then view them from there on the security tab.

Hi Phil, I have to retract part of what I stated earlier insofar as it's not true for local accounts on workgroup machines: the UAC does filter access tokens for local accounts only that are members of the local Administrators group (not domain accounts). Have a read of this article. In short, best practice is putting the local account into the Distributed COM Users group and assign access to the relevant WMI folders - both of which you have been doing. Only in the event that this isn't enough - which in turn depends on what it is you're trying to execute, do they suggest using the LocalAccountTokenFilterPolicy registry key. Cheers, Lain

Hi cron22, The support for the application has never been the greatest; though I have seen much worse. It takes a long time to get application update requests implemented. One of the requirements it has is that you use an account which is a Local Administrator on all of the target servers... In fact ... the vendor won't support the applicaiton if you don't have Local Administrator access! We have a number of Internet facing servers and the business owners of those boxes didn't want us to have an account with Local Adminsitrator rights. Fair enough too! So I asked the vendor if they could provide a list of the permissions the account actually needs but they refused to do so and would only specify that I needed to have a Local Administrator account. I had to go and figure out the required permissions by myself... I don't think using the Admin Shares is necessarily a bad idea if you are using a Local Administsator account. It's a quick and easy way to make sure the correct and latest version of the required WMI Provider is installed before the application connects to it. The problem is that we are now encountering some scenarios in which we effectively can't have a Local Administator account: 1. This scenario we have been discussing - a Stand-alone Windows 2008 server which has UAC turned on. For all intents and purposes it isn't possible to have a Local Administator account in this scenario. 2. Domain Controllers - there aren't any Local Groups on a DC so it isn't possible to have a Local Adminsitator and we certainly aren't allowed to have a Domain Administrator account. 3. Servers without Admin Shares - some business owners remove the Admin Shares for increased security. The Internet facing servers I mentioned above are one example. Strictly speaking we still have a Local Administrator account but this scenario is effectively an exception because we have to keep the WMI Provider updated manually (the same we we will have to do for the Stand-alone Windows 2008 servers). Given these three exceptions I think you're right - that the vendor should update the application to allow the option of using a different share name. We could then create a share called 'APP$', or whatever, and only give our application account access to use it. That would help us solve all three exceptions and enable us to use the application against all of the servers. Anyway ... to both you, - cron22 - and Lain Robertson, I just want to say thanks again for your time and help. I really appreciate it. I have a few options but ultimately I agree with cron22 that the applciation needs to be updated to account for the various exceptions. I will have to keep the WMI Provider updated manually for the next while as I work with the vendor to hopefully get the application updated... Thanks again! Phil

Hi Lain, Thanks again for getting back to me... Yes I have added the account to the Distributed COM Users group and I have given the group full control of the Root WMI Namespace and everything below it. That works and I can connect to WMI remotely using my Local Account. But that is not the problem! The first thing my application does is connect to one of the Admin Shares (e.g. C$ or ADMIN$) and installs the required WMI Provider. The issue being that the Local Account can't connect to the Admin Shares because it is not an Administatrator. That's why I am trying to update the permissions on the Admin Shares. Now then ... if the applicaiton isn't able to connect to an Admin Share (for this reason, or because they have been removed, or whatever) then it simply tries to connect to WMI anyway. In other words I can manually install the correct WMI Provider and then my application will work. The problem with that is I (or someone in Operations actually!) will then be required to keep the WMI Provider updated manually from here until eternity. Every time it is updated a Change will have to be rasied to update these servers and any other stand-alone Windows 2008 servers. I really don't want to do that! What I really want is to have the application working 'properly' and that's why I'm trying to find a way to update the Admin Share permissions. I will have a read of that article. Thanks very much for that. I have also gone back to the people who write the application and asked them if we could add an option of connecting to a different Share name. For example, instead of just trying to connect to the C$ or ADMIN$ Shares, perhaps the application could also try to connect to SOMETHINGELSE$ - then I could create the new Share and give it whatever permissions I like. That would also solve the problem. Thanks again for you help, Phil

If you ask me, the issue should reside with the creators of the application. I mean, why on earth would they use those shares knowing that they cannot be modified? Like seriously, isn't that asking for disaster?