Something to keep in mind. If you you ever have to do a fucking restore of a company and need to rename the .TLG file for the company file, do it for ALL the company files hosted on the server, too – apparently some licensing info can get dicked up and make accessing the company files a nightmare. Proper procedure, according to me now, is:
- Stop the QBdatabase27(or whatever) service.
- Rename each .TLG file to .tlg.old
- Restart the service
- Test each company file login
If you don’t, you may find yourself in an endless loop of stopping and starting and naming and renaming.
PS – Fuck QuickBooks support this morning. I asked for escalations twice and was met with, “Hmm. Well, let’s try this now.”
So, interesting thing: the other day one of the guest VMs was suddenly unreachable. Logged into the host and was able to ping it, but the network showed “unidentified public”, yada yada, fuck you, you can’t browse anywhere. Anywho, after fudging around with all the NIC settings in Hyper-V and the guest, I gave up due to lack of time and moved the application it used to another server. Then, what I thought was an unrelated issue, someone called to say they couldn’t scan, and the folder happens to reside on the host server. Checked the NIC properties and the NIC that the guest used lost its gateway. So, long story short, when looking at Hyper-V guest network issues, check the host NIC properties also.
Around here, it’s a pointless endeavor. No matter how many times I tell the users, and no matter how dumbed down I make the training, they still repeat the same idiocy. Today, for instance:
“See, and then when I click THIS it does…”
“Why are you clicking on it if you think it’s a problem?”
“I wanted to show…”
“What do I tell you guys about these things?”
“Not to open them?”
“Then why are you OPENING IT IN FRONT OF ME??”
“Because I wanted to show…”
Outlook 2016 doesn’t use OWA to connect outside the office like 2013 did – it relies solely on the published cert. If you don’t have one, or it’s just being a dick, you can do this. Specifically, the XML/reg thing.
Also, ran into this nonsense where I couldn’t add or remove profiles in Control Panel>Mail deal with 2013. Got around it using by using Run>outlook /profiles.
To continue the last post, the offending Buffalo Terastation has gone totally berserk. Today it has:
- Lost its IP configuration
- Had a drive fail
- Reverted back to an old admin password (the fuck?)
- Lost its IP information again
- Failed to backup….twice
- Miraculously regained its IP information
- Lost its IP information again
Look, I know shit happens, but this is ridiculous. Nice product, Buffalo!
The last few weeks have been a total shitstorm of knowledge.
Got an early AM call from a remote user unable to login to RDP. Came in and rebooted the TS, because it’d been awhile and it’s not terribly unusual to have login issues. That didn’t help. Shortly after, had a local user come in who couldn’t login – similar behavior, stuck at “Welcome”, yada yada, so thought maybe it was a DC issue. Bounced my DC, and shit all started going totally haywire.
Anyway, longish story short, after things slowly started coming around, noticed that the ONE thing still really fucked was access to network shares residing on my Buffalo Terastation, while shares on the file server were fine. Honestly, the NAS was in my head the whole time, but didn’t consider it quite enough. Powered it off and boom, everything was working properly and all the logins on the TS and locally processed immediately.
Not sure of the root yet, but I noticed that the jackholes prior to me didn’t configure it with static IP info – they simply reserved the IP in DHCP, so I think that may have been it. Why it never happened before? Who the fuck knows.
So, the lesson is, listen to your instinct…or at least calm down long enough to process it to see if it makes any sense.
One of our sales reps….wait, let me just say first, that the bastard texted me at 10 last night (Sunday) asking me to call him this morning to help him setup RDP. Like, emailing me this morning or calling himself wouldn’t be sufficient.
Anyway, this morning I forwarded him the document I sent out a few weeks ago instructing RDP users how to configure it. Turns out that 1. He doesn’t have his phone setup for email, which is great when you’re a sales rep and 2. He still hasn’t figured out OWA, so he never got the email.
Long story short, after literally telling him every letter and number to type in, he still got it all wrong, which didn’t matter anyway, because it turns out his fucking IP was blocked on the firewall because his other PC that apparently took a dive yesterday was port scanning the shit out of my WatchGuard.
So, I learned this: After finding their public IP (I had to login to his dumb Xfinity router), go to the Traffic Monitor and type the IP into the search field.
That’ll show you what’s going on. In this case, RDP wouldn’t connect, OWA wouldn’t connect and I couldn’t ping anything. The results should tell you “blocked sites”. Interestingly, if you actually look at the Blocked Sites under Firewall, you can’t fix it. You need to go to System Status>Blocked Sites, find the IP, highlight and delete. Which makes no sense to me, but whatever.
The last couple weeks were a complete nightmare. To recap – Exchange took a shit on me. One of the databases was creating insane log files. I watched it go from 4GB free to 0 in about ten minutes. Even though I was able to add 200GB in HyperV, it took hours to boot. Here’s what I learned:
- According to a bunch of articles I found re: Server 2012/Hyper V and “stuck at”, the hours long reboot was probably due to a bad update. It was stuck on “Do Not Shut Off”. Be patient. Don’t panic and try and bounce it again. Let the damn thing start. Explorer will eat shit and take forever to load everything, but it will all be up again in about two hours.
- Don’t mount the shitty database again if you can avoid it. Fortunately I only had about ten mailboxes, half of which were really, REALLY non-essential employees. I left the database dismounted, disabled the original mailboxes, recreated new ones and then restored them from .pst using Stellar Phoenix. Download it free first to make sure it will actually pull up the mailboxes. It’s around $300 to purchase. It’s not perfect, but it recovered enough for me to at least get people going and to buy me enough time to sort out the details.
Oh, and coincidentally, right after this, I had two client domains that we stopped receiving emails from. The two things they had in common were Office365 and spam protection. They were receiving different NDRs, making it really crappy to try and pin down. Noticed they never hit my internal spam filter or Exchange. After fiddling with TLS on Exchange and my WatchGuard, I took a shot at increasing the stupid WatchGuard’s incoming SMTP proxy nonsense….specifically the maximum header size, which is set to the default value of 20000 bytes. After increasing it to 80000 the emails all started coming in. Office365 must have noodled with something tiny that week, because the header sizes are all around 24000 bytes – just over the default and enough to block them at the firewall.
Well, I don’t know what’s going on, but…
You’re killing me, Smalls.