I have a windows service written in C# running on Windows Server 2012. The service is running as a domain user with permissions on the local machine and NTFS permissions to shared network resources on an Isilon SAN. I can access shared files and directories in Windows Explorer when logged on as this user with the following format:
\\isilon\path\to\dir\
However, calls to
System.IO.Directory.Exists()
always return false. At first I thought it was this:
http://support.microsoft.com/kb/827421
However, implementing the workaround suggests that you can use
System.IO.Directory.GetDirectories()
to just access the directories (without checking first if they exist) instead. This just throws
System.IO.IOException: An unexpected network error occurred.
This same service code works when running on another server (Windows 2008) on the same network.
What is really crazy is that if I reboot the server, the file system calls succeed at first. Then after some amount of time, or after accesses to the same file path from that computer, the programmatic calls will start to fail and will never spontaneously succeed again. Rebooting the server fixes the issue for a very short while.
I'm totally stumped as it shouldn't be necessary to reboot a Windows server instance hardly ever. I don't have any idea what could be affecting the fileshare permissions or accessibility. Maybe it is related to the new implementation of SMB 3.0 on Windows server 2012?
Edit: OK, It turns out that I'm not crazy. The version of OneFS (the FileSystem running on the Isilon SAN) was not explicitly compatible with Windows server 2012. While it claimed to be compatible with SMB. Updating from OneFS version 6.5.5.14 to 6.5.5.20 fixed the problem immediately and has been stable since.
Related
Tried with osFamily 4, osVersion *
Background: we have an app that uses System.Management.Automation.dll (from the GAC, dev box is W10) to work with Powershell in C# code. Specifically, we are using InitialSessionState and the ExecutionPolicy property - which we found out is part of WMF 5 (it errors out with not found exception on type load on the cloud service).
Now, this can be properly fixed by installing WMF 5 (we tried first via Remote Desktop; and no, forcing only the newer s.m.a.dll into the GAC does not work). Problem is, the installer asks for a reboot - and that I think is a problem with the startup task.
We added the installer to the setup.cmd that we already had:
Win8.1AndW2K12R2-KB3134758-x64.msu /quiet
It indeed automatically reboots the role instance, and runs setup.cmd again (which adds an error entry to the setup event log to the tune that it is already installed).
This reboot does not flag the cloud service deployment as failed. Which we are happy about but, is this really a supported behavior? or accidental?
Is there the supported way to make an installer work that requires a reboot? Or is the behavior we found the "supported" way?
There's not really a "supported" way - how you initialize your cloud service is really up to you. Having said that:
Given that cloud service role instances typically survive reboots, there's nothing wrong with setting something up that requires a reboot. Then it's a matter of dealing with already-installed software when returning from the reboot (e.g. leaving a breadcrumb file from your .cmd that installed the software initially). This is sometimes the only way you can install software (where reboots are involved), and utilizing a breadcrumb helps cut down on subsequent reboot time (the clock-time required to complete the boot process; not the number of actual reboots).
In this type of scenario, only the initial role instance boot has an additional reboot. (other reboots, from Guest OS and Host OS updates, or failed hardware etc., are separate, of course).
I have a .NET 4.0 C# console application. The application is deployed to a network file share (which I believe is a Windows 2000 Server file server) like this:
\\server\share\Apps\Beta\Group\JobName\JobName.exe
The agent machine that will execute the application is a Windows 2008 R2 Server, x64. I use a domain user account to run the application from the command line. When run under a certain account we'll call UserBeta, the application throws the following exception when trying to connect to a WCF service:
System.Configuration.ConfigurationErrorsException: Error creating the Web Proxy specified in the 'system.net/defaultProxy' configuration section. ---> System.Net.Sockets.SocketException: An invalid argument was supplied
The user account, UserBeta, has Modify, Read & Execute, List folder contents, Read and Write permissions introduced at the folder Beta and inherited by the child folders in the above path. If I use a second user account, UserStage, which has the same permissions except that they are introduced one folder higher, at the Apps folder, the application runs without exception. Both accounts belong to the local Administrators group on the agent server.
Interestingly enough, if the application is executed as UserBeta within 15 seconds or so of it being executed as UserStage, it will also run successfully.
I should also note that the application runs fine if run from a local drive as the GroupBeta account, so there seems to be some sort of trust issue with the particular account running from the network share.
I need the application to run as the UserBeta account from the network share. ClickOnce is currently not an option. I believe I could solve the problem by adding the permissions for UserBeta at the Apps folder, however I don't like throwing more access at something unless that's really the issue. If anyone has any other ideas or can point me to the reason adjusting permissions is the correct course of action, I'd be much appreciative.
On my test machine running (Windows XP, IIS5.1) the following code executed within a C# .NET WebService (.SVC) under a custom process identity (using machine.config to specify the user)
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
correctly returns
c:\Documents and Settings\myUserName\Application Data
However, on (Terminal Services) Windows 2003 machine running IIS6 and executing the same code but now using ApplicationPool to specify the same process identity the method returns:
c:\Documents and Settings\Default User\Application Data
Things I have checked while running on the Win2003/IIS6 machine:
myUserName belongs to the group IIS_WPG (even tried Admin)
a call to Environment.UserName correctly returns myUserName
a call to Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); also returns a 'Default User' path, likewise with DesktopDirectory
logged on as myUserName and ensured that C:\Documents and settings\myUserName exists
running the exact same code in a .net application on the Windows 2003 box, this works and returns the correct path.
I am baffled, it only occurs when runing under IIS6. It is almost like it thinks that the call is coming from Network Service or Local System users and it is not checking the Identity running the Application Pool.
Incidentally when I look at Procmon and watch a C++ application that is called from the webservice it has no such problem reading and writing to C:\Documents and settings\myUserName\ApplicatonData, it does not seem to have a problem, perhaps it builds the path differently.
I am starting to think this might be a bug in .NET??
Thanks.
Tom Deloford
Solved. Apparently this is 'by design' because IIS6 does not load user profile settings.
Microsoft advised me to upgrade to IIS7 or call LoadUserProfile first, I wonder what possessed them to change that functionality from IIS5.1.
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/890fa85a-b11a-4fbe-a333-cbe69abd72a7
Anyway lesson learned, don't assume functionality hasn't been removed and always test with the same application server even if annoys the IT department!
Yes. it's not a bug.
Under which user is running the app pool??
Let's split this a little:
The Test Machine uses IIS to host the service or the built-in web server?
If you use the built-in web server, it runs under your user.
If you use IIS, which one is the pool user?
If it is Network Service or Local System, the process runs under the context of one of those users, and indeed, the call to:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
is OK.
You should change the user of the pool (and recycle the pool) to see the change.
I have an XBAP that needs to be able to burn cd's. When running from inside Visual Studio, everything works okay. However when running from a browser, the IMAPI dll reports that the environment is not supported as soon as it tries to access the drive.
I am assuming this is coming down to permissioning. I have a signed certificate which I have installed and the xbap is set to run as a full trust application (although I'm guessing that it can't be or I wouldn't be having this problem).
Currently this is all running on my local machine, however eventually I want this to be deployed to a web server (all users will already have the certificate installed on their clients).
Does anyone have any ideas as to what I've missed / done wrong?
Update:
I have tried creating a new, test certificate which I've installed in my certificate store and then signed the XBAP against it, but it makes no difference.
Really could do with some ideas if anyone has any?
Further Update:
I have created a console application which is able to burn cd's. Shelling out to this console application allows me to burn the cd from my xbap, but not from inside the xbap itself.
However, this is really not what I want. Ideally I want to have all this contained within the xbap. Failing that, is there a way to include the console application in the xbap's one click deployment?
Thanks
I believe this is not possible to do with XBAP. According to MS documentation on XBAPs,
Examples of permissions not available
in the Internet zone:
FileIOPermission - This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission - This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode - This permission controls the ability to call native Win32 functions.
When you run your XBAP over the internet, you'll hit issue #3: trying to interop with unmanaged code.
I would recommend deploying your app as a stand-alone app with ClickOnce. That way, you can have full access to the system, but still get easy deployment and upgrades like you do with XBAP.
*edit*
One thing you could try -- and I can't guarantee it will work -- but you could have your users go into IE Internet Options, add your site to the trusted sites list. I'm betting then your CD burning code will work because it will be in the trusted zone, rather than the Internet Zone.
Try going to
HKLM\SOFTWARE\Microsoft.NETFramework\Windows Presentation Foundation\Hosting
in the registry
create a new DWORD named RunUnrestricted with value 1.
I have a small program that opens a file on a server share accross a local network.
This app is deployed to client machines in various sites. The infacstructure across these sites varies quite a bit and is quite shakey.
We have succesfully deployed this app to a few sites with no problems.
However our latest deploy the local share is on Small Business Sever 2003 (instead of windows server 2003).
We're getting an UnauthorizedAccessException when the the code tries to open a file on the server.
Looking at the File.Open documentation:
I can see that this exception might be thrown because "This operation is not supported on the current platform."
Has anyone had any similar problems with small business server 2003?
I know it may seem like I'm jumping to conclusions, but this is extremley difficult to test remotely because of infastructure problems.
I'm really just trying to rule stuff out.
There are two layers of access you require:
The Share: Do you have the correct access to the share.
The directory / files: Do you have access to the files
Is the SBS in the same domain as the client?
Try connecting to the SBS before you run the progam.