A good habit for an excellent IT system administrator

I have been an IT system administrator for a while and have visited various blogs and forums. I have read various technical posts and I am deeply touched by them:

It may be because of the first exposure of the system administrator's work environment. If my opinion is unreasonable, I would like to hear your opinions.

1. I don't need Administrator! Domain Admins!

I have seen many technical documents from my wife and deployed teaching documents. There are 10 articles and 9 articles in which the application is deployed using the domain Administrator,

I don't believe that the environment in which you work uses this account to deploy applications, because it is neither reasonable nor scientific. This account with the highest permissions is generally not required, the password may also be stored in a folder that is encrypted by the RMS in the deeper and deeper layers. This account has too many permissions and is highly risky.

If you are not using this account to deploy the system in the real environment, do not post such a blog post to avoid mistakes.

All applications should be deployed using common dedicated domain accounts, which will be described later. If you really need the Domain admins permission, I will also clearly explain in the document that, for example, the deployment of Exchange requires the standard three admins, Enterprise Admins, Domain Admins, Schema Admins. Deployment of most systems only requires common Domain users.

2. Disable the firewall first!

Well, my current company also disabled the firewall for all servers by default, but I do not recommend it. I can't change the company's policies. I don't know how our predecessors have come to the conclusion of shutting down the firewall.

Many companies need to enable the firewall for their default servers. I believe many new users can see that the server cannot be connected and the database cannot be accessed when referring to the document, especially when the application roles and databases are deployed separately. Then I went to consult the blogger at this time, and the blogger replied, first check if the database server's firewall is off. What should I do if my server cannot shut down the firewall?

All the firewalls in my article will not be closed. I will clearly tell you which ports of the firewall need to be enabled. Which permissions and roles are required to connect to the database. The system administrator should know which applications and services are connected through that port. You can spend several minutes to tell new users in the blog, saving the trouble of many new users hitting the wall.

3. Use your domain account as the administrator!

Well, I have to admit that my new company also asks me this way, and I will not make any comments.

All system deployment accounts and management accounts should not be domain accounts of ordinary employees, but should be special fixed accounts or user groups, such as XXadmin and XXXADMINS, the simplest reason is that when an employee leaves the company, the employee does not have any impact on any system. You only need to change the password of the special management account. After a new employee joins the company, it also makes it easier to add permissions. All applications I deploy myself use one or more special accounts.

4. Select Allinone and all functions!

What I see most is where SQL-related deployment is available. When it comes up, I will tell new users to Install SQL, check all functions, and add this installation account to sysadmin of the database. For example, if I have seen the SharePoint deployment document, write it, check all the functions of installing SQL, and add the account used to install SharePoint to sysadmin, there is no error in doing so, I just think it will mislead new users. In fact, we should only check the SQL DBengine. If SharePoint has a Report service, we should also check the Report service. If it is a cluster environment, therefore, reports do not support clusters and require a single job. The account for Sharepoint installation must be in the DBcreator group and Securityadmin Group of the SQL database. Since we write documents to teach others, we should be careful. Before that, I had to lead only one requirement for writing documents: If I write Exchange deployment documents, even if the person who looks at my documents doesn't even know what Exchange is, they can follow the document to build the environment step by step without any problems.

As for Allinone (All Feature in one machine), how can I at least separate the database from the application? Allinone can be set up on a temporary basis to test certain functions of the project. For more than a month of test or real environment, allinone should not be set up, and the multi-server environment is different from a single environment, only allinone, you cannot understand all the functions of this system.

5. Keep the default configuration and proceed to the next step!

I agree that most of the system deployment processes or after the deployment is completed, it is correct to use the default configuration for many configurations, but I think at least I want to explain and understand this location, what is the purpose of this check? Why is it checked? What will happen if it is not checked? It is described in the document. Otherwise, it is completely incomprehensible when new users are deployed.

I wrote so much at half past one. Please try again later.

This article is from the "absolute field" blog, please be sure to keep this source http://mingwang.blog.51cto.com/1997299/1352180