First of all. Do not try this on anything other than a disposable test farm.
I’m 99% certain Microsoft will laugh in your face if you do this to your production server and try to get support. Doing this on a client site would be reckless and irresponsible, this is posted for interests sake.
I was down the pub one evening and It occurred to me, what happens if you want to put all your logs on a mapped drive? It quickly occurred to me that I should drink more.
… Six months passed …
In the world of SANs my question doesn’t make that much sense. You build your aggregate, parcel it up into LUNs and attach them to the relevant hosts. We’re not talking about a significant improvement in performance, scalability, maintenance etc.
On the other hand if you’re got a big farm the idea of having 20 x 10GB disks with one attached to each server has to add to the complexity From an admin perspective it’s also a pain as your ULS files are all over the shop. But the main reason I want to do this is because I want to know if it can be done…
To assist me I have a friendly shared drive:
By default my install was using the C:\Program Files path, not best practice but this is a throwaway VM. It was good enough to start:
So, let’s try putting in my shared folder:
Unsurprisingly, SharePoint objected to my choice of paths. Normally this would be a good time to realise that this is a bad idea but let’s try something else:
Perhaps a mapped drive will do it (note I actually used H:\ instead). Once that’s created we can try using it instead:
I guess not. It seems SharePoint doesn’t like my idea as much as I do. Time to see if PowerShell also dislikes my clever plan …
It turns out that PowerShell will let us set it, even when the GUI complains! Score one for PowerShell! Note at this point a wider lesson, PowerShell will sometimes let you do things you can’t through the GUI. That can be a good thing or a bad thing.
Of course when I went back to check my folder I saw an ocean of emptiness, no log files. Event viewer tells us the folly of our ways…
There we can see our, not working, mapped drive. I wonder what happens if we try for the full house…
And if we force SharePoint to create a new log file using ‘New-SPLogFile’ then..
It works. Nothing new in the event viewer, log files seem to be being created correctly. The GUI still shows the old folder path and for any new servers you’ll get the same error message we saw above.
So it turns out that yes, you can use Network drives for SharePoint log files but doing so has some serious drawbacks:
- Probably out of support
- Inability to edit the diagnostic logs through the GUI afterwards
- Not thoroughly tested
- Adds to DR / new server build complexity
There’s probably a lot more but any one of the first three should stop you deploying to a live system.
On the other hand i’d quite like it if MS did open this up. Disavowing UNC paths might help to avoid some admins using a consumer grade NAS as if it was flash cached fiber SAN but it also restricts everyone else and i’m not sure if there’s a better reason.