To follow up on last post, you need ability to stream with WMS from network storage, and it isn't trivial at all.
Excellent solutions from newsgroup
microsoft.public.windowsmedia.server
Copy paste from Ravi Raman [MS]:
Hi Christer/Sachin,
This is going to be a lengthy post, so that I can get across what is
happening with the server here.
The server is running is running under Network service account. This
account impersonates the computer account when in a domain. So, things are
a little bit easy when you are in a domain - give the computer account
access to the file share and this problem is solved.
When it is not in a domain, this Network Service is an unknown user when it
accesses any file on another computer. Since the account under which the
service runs is not recognized by the remote file share, if the file share
has any access control on it, it won't let the server open the files. Also,
a service (on both domain and non-domain settings) does not understand
drive mappings - so you should use full UNC path as your source.
For on demand publishing points (on both domains and non-domains), there is
additional restriction with the NTFS ACL plug-in which cannot successfully
get access if it tries accessing files on a remote file share. The NTFS ACL
plug-in doesn't apply to broadcast.
To make on demand and broadcast scenarios work from a remote file share we
need to a) make sure the account under which service runs has access to
file share and other resources b) and for on demand pub points, ensure that
NTFS ACL check does not happen.
Here is a step by step run down to make your scenario work. It should work
for remote file share, but not sure about NAS. Since this is a work around
that I haven't fully tested, I suggest you do this on test machines to see
if it works.
1. This step is applicable only if you source On Demand from a file share:
Go to server->Properties->Authorization. Disable "WMS NTFS ACL
Authorization". But once you do this, you will need to go to each on demand
publishing point that sources from a Local drive and enable this plug-in on
them to maintain the same level of security. In short NTFS ACL should be
disabled at server level and at publishing point level for all on demad
publishing point sourcing from remote file share.
2. Create an account (say "WMSvcAcct" ) that has the SAME password on the
file share machine AND WMServer machine.
3. On the file share, give the local WMSvcAcct read permissions on the file
share and the physical directory.
4. On the WMServer machine, give the WMSvcAcct account the following
accesses (or better yet, just give whatever permissions Network Service
currently has):
- %WINDIR%\system32\windows media\server directory - Full Control to all
subdirectories and files under this.
- %SystemDrive%:\wmpub\wmroot - Read access (if you access from default
publishing point)
- %SystemDrive%:\wmpub\wmarchive - Read+Write access (if you are
archiving)
- %WINDIR%\system32\logfiles\wms - Read+Write access (if you enable
logging)
- Any other directory that your on demand publishing points source from.
Registry keys:
- HKLM\Software\Microsoft\Windows Media\Server\Namespace\Storage - Full
control
5. Also on WMS box, go to Local Security Policies->Local Policies->User
Rights Assignment - find all the privileges given to Network Service and
give it to this WMSvcAcct.
6. Go to the Computer management->services. Find Window Media Services,
double click and choose the Logon option. Enter the username and password
for WMSvcAcct to make the WMServer service run under WMSvcAcct account.
This account is available on the file share with same password, so this
makes it possible for the server to access content on a file share.
This should get remote file share scenario going in a pretty secure
setting. I will try to find if there is a better way of doing this and if
there is a way around for NAS.
Thx,
Ravi
Thanks Ravi.
