Okay so there is so much that can go wrong when you deploy printers via GPP. So let's take this slow:
Assumptions: clean machine with no drivers
Computer Policy Settings
Admin Templates --> Printers
1. Disable - Point and Print Restrictions
2. Enable - Extend Point and Print connection to search Windows Update
http://technet.microsoft.com/en-us/library/cc754294.aspx
Tips, tricks, and scripts for Admins on the run. Also this serves a a brainless repository for me when I know I'll need it later.
Wednesday, May 23, 2012
OABGen encountered error 80040115 or EVENT LOGs 9334/9330
So I had a client who has 2 hub servers and 3 mailbox servers. Exchange is housed in the parent domain and they have a child domain. The complained that the Offline address book was not synchronizing properly since the migration to exchange 2010 occurred from old and dusted groupwise.
Sure there are tons of posts with this specific issue and several blogs say check DNS, addressing issues, registry , etc (source: http://blogs.msdn.com/b/dgoldman/archive/2007/11/15/oab-generation-fails-to-generate-with-errors-9330-and-9334.aspx ).
The event logs on the server generating the OABs in my case were exactly the same messages as the post above; the only thing to note was the, server that was failing, was being referenced was the DC in the child domain. A packet capture I had done initially showed traffic being passed to the correct server. So I went down a rabbit hole that didn't pan out. As it turns out that in other logs the FQDN of this server was referenced but NOT for the OAL gen process. So I appended the child domain name to the DNS suffixes in the order of parent domain, child domain.
Updated the OAB again and successfully resolved the issue.
OABGen encountered error 80040115 while initializing the offline address book generation process. No offline address books have been generated. Check the event log for more information.
- \OABv2
OABGen encountered error 80040115 (internal ID 50004b2) accessing Active Directory
- \OABv2
Monday, May 21, 2012
Thursday, May 17, 2012
Best practices: Virtual Active Directory Domain Controllers
Here's a number of best practices for virtual domain controllers:
- Never, ever snapshot, never pause, and never clone via vmware client
- Educate yourself on your backup solution and it's AD backup capabilities
- Time Sync, is still very important. Insure your host is sync'd or setup external time source
- vmtools client, if stopped/crashed can cause time issues
- Make sure you can restore, not just backup. Backups are useless if you can't restore. The right backup solution will auto-verify the integrity
- Anti-affinity, make sure your DC's don't end up on the same host.
Subscribe to:
Posts (Atom)