I will leave out the 'how we came to this conclusion' part, but suffice to say it took 3 people the better part of 2 full days. There is a, in my humble opinion, rather gaping bug in 2012R2 IIS that manifests itself like this: You have many file changes in the web root, but they are contained to the 'safe' directories (i.e. not in /bin or whatnot) In theory, IIS doesn't care and you go about your merry way - because it only monitors /bin and /app_data (iirc?) and some config files You find yourself chasing spikes in your (New Relic) data, traces that make no sense (the transactions that get called the most have a lot of looong traces) Nobody understands what's going on, because no errors are being thrown You can verify that you're seeing a lot of ASP.NET app domain restarts by looking at perfmon: ASP.NET Applications - (your instance) - Application Lifetime Events What you should be seeing upon a legit recycle is one startup event and one sh...
This warning isn't documented that well on the googles, so here's some google fodder: You are trying to set up replication for a DFS folder (no existing replication) Source server is 2008R2, 'branch office' server is 2012R2 (I'm moving all our infra to 2012R2) You have no issues getting replication configured You see the DFSR folders get created on the other end, but nothing stages Finally you get EventID 4312: The DFS Replication service failed to get folder information when walking the file system on a journal wrap or loss recovery due to repeated sharing violations encountered on a folder. The service cannot replicate the folder and files in that folder until the sharing violation is resolved. Additional Information: Folder: F:\Users$\user.name\Desktop\Random Folder Name\ Replicated Folder Root: F:\Users$ File ID: {00000000-0000-0000-0000-000000000000}-v0 Replicated Folder Name: Users Replicated Folder ID: 33F0449D...
Fun time figuring this out, I was being bad and not documenting, but here's what I recall: Kept getting 'access denied by server while mounting' errors when using this command: mount -t nfs 10.0.0.14:/volume1/mysql_backup /srv/backup Checked and re-checked the Synology settings to no avail. Thought it was something to do with root squash - was not. Correct settings should be correct IP address, RW, No Mapping, Enable Async SSH'd in to the Synology and after some messing about with /etc/exports, I set up tail -f /var/log/messages Took me a while to notice it, but the IP it was registering was the Astaro gateway IP - the Synology and my PC are on different subnets! Set the NFS rule to '*' and started working immediately. Firewalls make it easy to overlook simple things. I imagine there is some sort of fancy NAT rule for the NFS traffic that would allow specific IPs, but seeing as how I'm technically behind two firewalls and this is a lab, the allow ...
Comments
Post a Comment