Forum Replies Created
Ditto on using WSUS. As for third party application updates, yes you should be updating them. Third party applications are an oft-used attack vector. You can use something like Ninite Pro to automate these updates. You should be able to eliminate most, if not all, of the manual updating that you’re doing by using WSUS and Ninite Pro.
We’re not a tutorial site. Microsoft has plenty of documentation in the Office 365 Security and Compliance admin center that you can read. Furthermore, we couldn’t help you as we have no idea what your security and compliance needs and requirements are.tdbchess;n517639 wrote:Hi all,
What is the best practice :
Actually, when a user leaves the company we disabled computer and user accounts, and move them to a specific OU like “Disabled Accounts”.
We never delete them.
Thanks for help
Best practice is whatever your company decides is the appropriate action.
Prior to Windows Server 2016, the Windows Time service was designed to keep time in a domain in sync within 5 minutes. If you have a 3 minute time difference then that isn’t a problem you’re going to find a solution for, nor is it withing the bounds of what Microsoft would consider a problem.bigalusn;n517348 wrote:supervisor is still undecided. So if we do decide to use a hybrid exchange deployment, will my abc.local and not abc.com be an issue?
As Ossian stated, you’ll add abc.com as a UPN Suffix in your on premises AD and set that UPN Suffix on all user accounts. You’ll then add abc.com as a verified domain in Office 365.
If you’re not planning on syncing your on premises AD to Office 365 then a Hybrid Exchange deployment isn’t an option for you, so there’s really nothing you need to do internally. You’ll set up your Office 365 tenant, add and verify your domain (abc.com), create your Office 365 users, assign them licenses, and cut over your DNS records once you’ve migrated the mailbox contents for your on premises users to their Office 365 mailboxes. Note that these Office 365 users will be “Cloud” users, meaning they’re not synced to an on premises AD user so things like SSO will be unavailable to them. You’ll also need to disable the internal SCP lookup method for Outlook Autodiscover after you’ve migrated to Office 365. Removing Exchange from on premises should do that for you, but you need to be aware that in can cause Outlook to find your on premises Exchange server until the SCP is removed or until the SCP lookup method is disabled.
A lot of this depends on whether or not you want to sync your on premises AD with Azure AD. I will tell you that if you sync your on premises AD with Azure AD then you will need to leave your on premises Exchange server in place. The Exchange related attributes (of users, groups, contacts, etc.) can only be managed on premises. If you choose not to sync your on premises AD with Azure AD then this is not an issue.
Which are you planning?May 20, 2018 at 1:05 pm in reply to: Primary DC Failed, Having Issues w/ Secondary DC Taking Ownership of Roles #304630
Make sure that DC02 uses itself for Primary DNS and uses 127.0.0.1 for Secondary DNS. Then open ADUC and changed the Domain Controller it’s trying to connect to.April 19, 2018 at 8:03 pm in reply to: Only have a Primary DC (Server 2000!) and need to figure out how to upgrade it #304628
“There is no group policy going on that I know of.” Of course there is. There are two default Group Policy objects created when the domain was created.
“According to Microsoft, the only next thing compatible with our server is Server 2003” – That’s not the case. See here: https://docs.microsoft.com/en-us/win…ctional-levels
There’s no reason you can’t incrementally introduce a new DC with a newer OS that supports your current Forest and Domain FFL’s and and then gradually raise your Forest and Domain functional levels until you’re where you want to be. You simply need to introduce the new DC, retire the old DC, raise the FFL’s, rinse and repeat.
There’s no such thing as a PDC or a BDC. If the server holding the FSMO roles has crashed and can’t be recovered then you need to sieze the FSMO roles to the other DC. You’ll also need to reconfigure the time service on the second DC to sync time to a reliable external time source. Also make sure that the DNS client settings on the second DC are correct. It should use itself for primary DNS and it should use 127.0.0.1 for secondary DNS. **DO NOT ATTEMPT TO RECONNECT THE FAILED DC TO THE NETWORK.**March 9, 2018 at 6:07 pm in reply to: How often do wsus clients contact with the wsus server? #304622
By default, the Windows Update client checks for updates every 22 hours.
Have a look here and step through the wizard of your choice.5habbaranks;n516099 wrote:Ah cool so this is for Azure based syncing not on prem syncing. The free Azure AD connect application is all I need and the only licensing I need to assign is one of the O365 E1, E3 etc?
I don’t understand what you’re asking.
Azure AD Connect is used to sync your on premises AD users and groups to your Azure AD tenant which you get with your Office 365 subscription. You don’t need any of the Azure AD Premium licenses. Azure AD Free is what you’ll get with your Office 365 subscription and that’s all you need.
You DO NOT need Azure Active Directory Premium P1 to use Azure AD Connect. Azure AD Connect is available and supported with Azure Active Directory Free, which is the base Azure AD you get with every Azure/Office 365 subscription.February 5, 2018 at 6:39 pm in reply to: How to catch up with 4 years worth of service packs, hotfixes, patches #304614
“Overall, what is the best way to proceed here? Do the patches have to be applied in reverse order and how to determine which are absolutely essential?”
Windows will take care of installing updates in the proper order. You simply need to check for updates, select all available updates, and select to install them. All updates that aren’t optional should be installed at the very minimum. This really isn’t complicated. The number of updates doesn’t change anything. Proceed with installing updates just as you would if there were only 2 updates needed, or 3, or 4, etc. You’re probably going to find that you need to run the update process a number of times to get the servers current with updates.December 17, 2017 at 7:38 pm in reply to: unable to telnet port 389 on a newly installed windows 2012 server #304613
If there’s no process or service listening on that port then telnet can’t connect to that port.