IT Questions and Answers :)

Sunday, August 25, 2019

Which of the following are NOT one of the four principles of object oriented programming (OOP)?

Which of the following are NOT one of the four principles of object oriented programming (OOP)?

  • Inheritance
  • Polymorphism
  • Abstraction
  • Encryption 
Which of the following are NOT one of the four principles of object oriented programming (OOP)?

EXPLANATION

The four principles of object-oriented programming are encapsulation, abstraction, inheritance, and polymorphism.

These words may sound scary for a junior developer. And the complex, excessively long explanations in Wikipedia sometimes double the confusion.

 

Share:

What Microsoft SQL server command lets you issue CREATE TABLE, CREATE VIEW, and GRANT statements in one command?

What Microsoft SQL server command lets you issue CREATE TABLE, CREATE VIEW, and GRANT statements in one command?

  • CREATE SCHEMA
  • INSERT INTO
  • CREATE PACKAGE
  • CREATE CLUSTER 

EXPLANATION


Creates a schema in the current database. The CREATE SCHEMA transaction can also create tables and views within the new schema, and set GRANT, DENY, or REVOKE permissions on those objects.



Syntax

-- Syntax for SQL Server and Azure SQL Database  
  
CREATE SCHEMA schema_name_clause [ <schema_element> [ ...n ] ]  
  
<schema_name_clause> ::=  
    {  
    schema_name  
    | AUTHORIZATION owner_name  
    | schema_name AUTHORIZATION owner_name  
    }  
  
<schema_element> ::=   
    {   
        table_definition | view_definition | grant_statement |   
        revoke_statement | deny_statement   
    }  
-- Syntax for Azure SQL Data Warehouse and Parallel Data Warehouse  
  
CREATE SCHEMA schema_name [ AUTHORIZATION owner_name ] [;]  

Arguments

schema_name
Is the name by which the schema is identified within the database.
AUTHORIZATION owner_name
Specifies the name of the database-level principal that will own the schema. This principal may own other schemas, and may not use the current schema as its default schema.
table_definition
Specifies a CREATE TABLE statement that creates a table within the schema. The principal executing this statement must have CREATE TABLE permission on the current database.
view_definition
Specifies a CREATE VIEW statement that creates a view within the schema. The principal executing this statement must have CREATE VIEW permission on the current database.
grant_statement
Specifies a GRANT statement that grants permissions on any securable except the new schema.
revoke_statement
Specifies a REVOKE statement that revokes permissions on any securable except the new schema.
deny_statement
Specifies a DENY statement that denies permissions on any securable except the new schema.

Remarks

Note
Statements that contain CREATE SCHEMA AUTHORIZATION but do not specify a name, are permitted for backward compatibility only. The statement does not cause an error, but does not create a schema.
CREATE SCHEMA can create a schema, the tables and views it contains, and GRANT, REVOKE, or DENY permissions on any securable in a single statement. This statement must be executed as a separate batch. Objects created by the CREATE SCHEMA statement are created inside the schema that is being created.
CREATE SCHEMA transactions are atomic. If any error occurs during the execution of a CREATE SCHEMA statement, none of the specified securables are created and no permissions are granted.
Securables to be created by CREATE SCHEMA can be listed in any order, except for views that reference other views. In that case, the referenced view must be created before the view that references it.
Therefore, a GRANT statement can grant permission on an object before the object itself is created, or a CREATE VIEW statement can appear before the CREATE TABLE statements that create the tables referenced by the view. Also, CREATE TABLE statements can declare foreign keys to tables that are defined later in the CREATE SCHEMA statement.
Note
DENY and REVOKE are supported inside CREATE SCHEMA statements. DENY and REVOKE clauses will be executed in the order in which they appear in the CREATE SCHEMA statement.
The principal that executes CREATE SCHEMA can specify another database principal as the owner of the schema being created. This requires additional permissions, as described in the "Permissions" section later in this topic.
The new schema is owned by one of the following database-level principals: database user, database role, or application role. Objects created within a schema are owned by the owner of the schema, and have a NULL principal_id in sys.objects. Ownership of schema-contained objects can be transferred to any database-level principal, but the schema owner always retains CONTROL permission on objects within the schema.
Caution
Beginning with SQL Server 2005, the behavior of schemas changed. As a result, code that assumes that schemas are equivalent to database users may no longer return correct results. Old catalog views, including sysobjects, should not be used in a database in which any of the following DDL statements have ever been used: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. In such databases you must instead use the new catalog views. The new catalog views take into account the separation of principals and schemas that was introduced in SQL Server 2005. For more information about catalog views, see Catalog Views (Transact-SQL).
Implicit Schema and User Creation
In some cases a user can use a database without having a database user account (a database principal in the database). This can happen in the following situations:
  • A login has CONTROL SERVER privileges.
  • A Windows user does not have an individual database user account (a database principal in the database), but accesses a database as a member of a Windows group which has a database user account (a database principal for the Windows group).
When a user without a database user account creates an object without specifying an existing schema, a database principal and default schema will be automatically created in the database for that user. The created database principal and schema will have the same name as the name that user used when connecting to SQL Server (the SQL Server authentication login name or the Windows user name).
This behavior is necessary to allow users that are based on Windows groups to create and own objects. However it can result in the unintentional creation of schemas and users. To avoid implicitly creating users and schemas, whenever possible explicitly create database principals and assign a default schema. Or explicitly state an existing schema when creating objects in a database, using two or three-part object names.
Note
The implicit creation of an Azure Active Directory user is not possible on SQL Database. Since creating an Azure AD user from external provider must check the users status in the AAD, creating the user will fail with error 2760: The specified schema name "<user_name@domain>" either does not exist or you do not have permission to use it. And then error 2759: CREATE SCHEMA failed due to previous errors. To work around these errors, create the Azure AD user from external provider first and then rerun the statement creating the object.

Deprecation Notice

CREATE SCHEMA statements that do not specify a schema name are currently supported for backward compatibility. Such statements do not actually create a schema inside the database, but they do create tables and views, and grant permissions. Principals do not need CREATE SCHEMA permission to execute this earlier form of CREATE SCHEMA, because no schema is being created. This functionality will be removed from a future release of SQL Server.

Permissions

Requires CREATE SCHEMA permission on the database.
To create an object specified within the CREATE SCHEMA statement, the user must have the corresponding CREATE permission.
To specify another user as the owner of the schema being created, the caller must have IMPERSONATE permission on that user. If a database role is specified as the owner, the caller must have one of the following: membership in the role or ALTER permission on the role.
Note
For the backward-compatible syntax, no permissions to CREATE SCHEMA are checked because no schema is being created.

Examples

A. Creating a schema and granting permissions

The following example creates schema Sprockets owned by Annik that contains table NineProngs. The statement grants SELECT to Mandar and denies SELECT to Prasanna. Note that Sprockets and NineProngs are created in a single statement.
USE AdventureWorks2012;  
GO  
CREATE SCHEMA Sprockets AUTHORIZATION Annik  
    CREATE TABLE NineProngs (source int, cost int, partnumber int)  
    GRANT SELECT ON SCHEMA::Sprockets TO Mandar  
    DENY SELECT ON SCHEMA::Sprockets TO Prasanna;  
GO   

Examples: Azure SQL Data Warehouse and Parallel Data Warehouse

B. Creating a schema and a table in the schema

The following example creates schema Sales and then creates a table Sales.Region in that schema.
CREATE SCHEMA Sales;  
GO;  
  
CREATE TABLE Sales.Region   
(Region_id int NOT NULL,  
Region_Name char(5) NOT NULL)  
WITH (DISTRIBUTION = REPLICATE);  
GO  

C. Setting the owner of a schema

The following example creates a schema Production owned by Mary.
CREATE SCHEMA Production AUTHORIZATION [Contoso\Mary];  
GO  


Share:

What do you use the CREATE TABLESPACE command for in SQL?

What do you use the CREATE TABLESPACE command for in SQL?

  • To create a database trigger
  • To add/rename data files, to change storage
  • To create a space for a table
  • Storing scheme objects, rollback segments, files 

EXPLANATION

Creating Basic Tablespaces: Examples
This statement creates a tablespace named tbs_01 with one data file:
CREATE TABLESPACE tbs_01 DATAFILE 'tbs_f2.dbf' SIZE 40M ONLINE;
It sound like you are new to Oracle databases. Oracle provides a wealth of documentation at http://docs.oracle.com/en/database. Specifically, I recommend reading their excellent introduction to the database called the Concepts Guide.

 

Share:

Which is the default port for secure SMTP traffic?

Which is the default port for secure SMTP traffic?

  • 995
  • 25
  • 110
  • 465 
Which is the default port for secure SMTP traffic?

EXPLANATION

Interestingly, port 465 was never published as an official SMTP transmission or submission channel by the IETF. Instead, the Internet Assigned Numbers Authority (IANA), who maintains much of the core internet infrastructure, registered port 465 for SMTPS. The purpose was to establish a port for SMTP to operate using Secure Sockets Layer (SSL). SSL is commonly used for encrypting communications over the internet.

 SMTP standard sends email without using encryption or authentication, every message you send is exposed to view. Client-side solutions such as Secure MIME (S/MIME) or pretty good privacy (PGP) can solve this problem, but they require your users' involvement. A better place to focus your security efforts is on securing SMTP traffic. If you can secure SMTP, you'll go a long way toward providing 100 percent security for mail traffic that originates or terminates at one of your servers.
Microsoft Exchange Server offers several tools for securing email traffic. One way to secure SMTP is to require the use of Secure Sockets Layer (SSL) for SMTP connections. However, that approach raises a problem. By default, all SMTP servers use port 25. But if you use SSL on port 25, non-SSL servers won't be able to connect through that port. And if you use a nonstandard port number, other servers won't be able to find your servers.


You can work around this problem. The STARTTLS verb (part of the Extended SMTP—ESMTP—command set) lets an SMTP client and server negotiate the use of Transport Layer Security (TLS) for an SMTP connection. Each end of the connection can choose to authenticate the other, or the TLS connection can be used purely for privacy. Either way, this approach offers three important advantages.
  • It doesn't interfere with other servers and clients. Clients that support STARTTLS can use it; those that don't can continue to use unencrypted SMTP.
  • It's opportunistic. When you enable the use of TLS with SMTP, your server automatically requests TLS when communicating with other servers, and it accepts TLS connections when requested. Assuming the other server completes the negotiation process, mail flow is automatically protected. (You'll generally need to tell your users to enable SSL/TLS in their Internet mail clients, though.)
  • TLS-encrypting the SMTP stream also protects message headers, giving you an additional degree of protection against traffic analysis, which can tell network intruders who you're communicating with, and how often.
You must remember one important caveat, however: TLS doesn't protect messages from end to end. In other words, it doesn't protect messages that are in storage or traveling from client to server (unless the client also supports TLS). TLS protects the message only as it passes between two servers that both support TLS.
Requesting an SSL Certificate
Before you can begin to use TLS with SMTP, you must obtain and install a certificate for your SMTP server. If you've already set up your own certificate authority (CA), you'll find that requesting an SSL certificate is quite simple; if not, you'll need to save the certificate request to a file and deliver it to your preferred CA. (For a detailed explanation of how to set up and use the Microsoft CA or how to use an external CA for your public key infrastructure—PKI—see the Certificate Services topic in Windows Server Help.) I assume that you have access to a CA of some sort and want to request and install an SSL certificate for use with Microsoft Outlook Web Access (OWA), IMAP, POP, or SMTP.
The basic mechanics of certificate issuance are the same for all these protocols, although I deal with only SMTP here. You initiate the certificate request process from Exchange System Manager (ESM). In ESM's treeview pane, navigate to your server, then to Protocols. Select SMTP, then right-click the virtual server and select Properties. On the Access tab, you'll see the Certificate button, which is enabled whenever you run ESM on an Exchange server. Because the private key associated with the certificate is generated on the local machine, generating a certificate from your administrative workstation doesn't make sense.
You can use Internet Services Manager (ISM) 5.0 to request a certificate for use with OWA. However, using ESM to request POP and IMAP certificates is easier because you can request them from the virtual server Properties dialog box, so that's what we do here. To request a certificate, simply click Certificate.
Getting a Certificate
When you click Certificate on a server that doesn't have a certificate for the specified protocol, ESM launches the IIS Certificate Wizard. The wizard will look familiar if you've ever used Microsoft IIS to request an SSL certificate. To request a certificate for Exchange to use, you must have administrative privileges on the Exchange server and the account you use must have permission to request the certificate from the CA.
After clearing the welcome screen, you need to specify what you want to do. If you're requesting a certificate for a virtual server that doesn't currently have one, your choices are to attach an existing certificate to the virtual server, import a backed-up certificate, or request a new certificate. If you're modifying an existing certificate, the wizard asks you to choose between renewing the certificate, removing it from the virtual server, and requesting a new one. Let's assume that you want to request a new certificate. After you click Create a new certificate, the process works as follows:
  1. The Delayed Or Immediate Request page lets you choose to use a remote procedure call (RPC) to send the request directly to an online CA or to save the request in Public-Key Cryptography Standards (PKCS) #10 format—the standard format used to request certificates. If you're using your own internal CA and the CA is online, select Send the request immediately to an online certification authority and click Next. If you're using an external CA or if your internal CA is offline, select Prepare the request now, but send it later, then click Next to generate a PKCS #10 file that you can send to the CA later.
  2. The wizard prompts you for a name and a key length for your certificate, as Figure 1 shows. Although Windows 2000 supports 512-bit keys, they are too short to be secure; always choose a key length of at least 1024 bits. Click Next.
  3. The wizard asks you to identify your organization and organizational unit (OU). These attributes are encoded into the issued certificate, so getting them right is important—the information you enter here is permanent. You have to type the information, so be sure you spell everything correctly. When you're satisfied with your entries, click Next.
  4. The wizard next asks for your site's common name (CN). The CN should be your server's Fully Qualified Domain Name (FQDN) as it will appear on the Internet. For example, if your SMTP server is exch-smtp-sea-1.fabrikam.corp and it has the external DNS name mail1.fabrikam.com, you'd enter mail1.fabrikam.com on this wizard page. If your machine's CN changes, you'll need to get a new certificate. Be sure to enter the correct DNS name—if you get it wrong (e.g., if the actual FQDN and the one in the certificate don't match), client applications such as Microsoft Internet Explorer (IE) will complain that the certificate is bad.
  5. The Geographical Information page asks you to pick the country (or region), the state (or province), and the city that you want in the certificate attributes. These entries aren't checked for validity, so be sure that what you enter here is what you want your certificate to say.
Up to this point, the procedure is the same whether you request a certificate from an online or offline CA. After you provide your geographic information, an online request prompts you to select the CA you want to use from a list of CAs visible to the requestor. (If the CA you want to use isn't listed, you can't submit a certificate to it.) Select a CA, then click Next. You'll see a summary screen of the parameters you've requested for your certificate; clicking Next again sends the request. When the request is successful, the certificate is installed automatically and you can begin configuring TLS.
Using a Third-Party CA
If you selected Prepare the request now, but send it later to submit a certificate to a CA outside your network or to a standalone CA that isn't integrated with Active Directory (AD), your submission process will be a bit different. After you provide geographic information, the wizard lets you choose where to save the request file. The request file is a plaintext, base-64­encoded PKCS #10 request. After saving the file, you need to submit it to your CA, typically through a Web-based interface. The details of the interface depend on the CA; for example, the interfaces for Thawte, VeriSign, and Comodo's InstantSSL look and behave somewhat differently from one another. Most vendors' Web sites prominently feature a set of instructions for submitting a request.
Microsoft's CA can also accept PKCS #10 requests through its Web interface. Let's walk through the process of using this CA to request and install a certificate.
  1. On your Exchange server, open IE and navigate to http://yourCA/certsrv, where yourCA is your CA's NetBIOS or DNS name. You should see the CA Welcome page. Select Request a certificate and click Next.
  2. The Choose Request Type page, which Figure 2 shows, asks you to select a request type. Because you want a certificate for a virtual server and you already have a saved request, select Advanced request and click Next. (The User certificate request list is for those who are requesting an end-user certificate.)
  3. The Advanced Certificate Requests page gives you three choices: submit a new request by using the CA's forms interface, submit a precreated PKCS #10 request, or request a certificate for a smart-card user. Because you want to use your existing certificate request, select Submit a certificate request using a base64 encoded pkcs #10 file or a renewal request using a base64 encoded pkcs #7 file, then click Next.
  4. The Submit A Saved Request page, which Figure 3, page 83, shows, is where you submit your request for processing. Use Notepad to open the PKCS #10 file on the machine on which your browser is running. Copy the file's contents and paste them into the Saved Request text box. (If you've configured the certificate server as a trusted site, you can use the Browse link to find and upload the request file.) Click Submit, and the system sends the request to the CA for processing.
You're not finished yet. As the Submission Confirmation page tells you, you need to return to the CA to check the status of the request and retrieve the issued certificate. (Depending on whether you're using an enterprise or standalone CA, the CA might automatically issue the certificate or require administrator intervention. For information about the difference between enterprise and standalone CAs, see the Certificate Services documentation in Windows Server Help.) To do so, return to the CA Welcome page at http://servername/certsrv, where servername is the name of your server. Select Check on a pending certificate, then click Next. The CA lists all known pending requests. Select yours, then click Next.
What you see then depends on whether the CA has issued your certificate. If it hasn't, the CA Web page tells you that the request is still pending. In that case, you'll need to approve the request (or have it approved). For an explanation of how to use the Microsoft Management Console (MMC) Certificate Services snap-in to approve a request, see the sidebar "Approving Pending Requests." If the CA has issued the certificate, you'll see a page like the one that Figure 4 shows. This page is a little confusing because it offers no clearly labeled "Download my new certificate" link. Click Download CA certificate and save the resulting file on your Exchange server. ESM expects the certificate to be stored in the Distinguished Encoding Rules (DER)­encoded format, so be sure to choose that format when you save the certificate.
After you save the certificate, you're ready to associate it with your virtual server. Return to ESM, find the virtual server to which you want to attach the certificate, and open the server's Properties dialog box. On the Access tab, click Certificate to start the IIS Certificate Wizard. This time, the wizard states that a certificate request is pending; select Process the pending request and install the certificate. On the next page, specify the path to the certificate file you just downloaded, and click Next. ESM decodes the certificate and shows you a summary screen so that you can verify that you're installing the right certificate. When you're satisfied, click Next once more, then click Finish to install your certificate. To verify that the certificate is installed, check the status of the Access tab's Communications button—this button is available only when a valid certificate is installed for the virtual server.
Enabling STARTTLS
With a certificate in place, you can start using it to protect your SMTP traffic. You have three choices: You can force the use of TLS for all outbound mail; you can use TLS for mail to selected domains; or you can force other servers that contact you to use TLS. These options are independent of one another, so you can use them individually or together.
To turn on TLS for all outbound mail on a selected SMTP virtual server, go to the Delivery tab on the SMTP virtual server's Properties page. Click the Outbound Security button to display the Outbound Security dialog box, which Figure 5 shows. Select the TLS encryption check box and click OK. However, be aware that this option effectively restricts Exchange to communicating only with hosts that support TLS. This restriction has the unwelcome side effect of making email messages sent to other hosts sit in delivery queues forever, or until the retry interval expires and the messages are returned with a nondelivery report (NDR).
A better approach is to use SMTP connectors to tailor the use of TLS to specific domains. You're almost certainly better off restricting your outbound TLS use to domains that you know support TLS. (To find out whether a domain supports TLS, telnet to port 25 on the domain's mail server and run the SMTP EHLO command from a command prompt. If the response lists STARTTLS, the domain supports TLS.) The easiest way to tailor the use of TLS is to create SMTP connectors for domains that support TLS, which you do from within ESM's Routing Groups container. When you create the connector (or modify the properties of an existing container), the two crucial steps are to ensure that you've specified the correct domains in the Address Space tab and to ensure that you've turned on TLS on the Advanced tab (click the Advanced tab, click Outbound Security, and select the TLS encryption check box).
Turning on inbound TLS is almost as easy. Go to the Access tab on the virtual server's Properties page, then click Communication in the Secure Communication command group. In the Security dialog box, which Figure 6 shows, you can turn on TLS at its default 40-bit strength or specify the full (and highly recommended) 128-bit version. Be aware that selecting the Require secure channel check box does exactly that: Servers that don't support TLS, or can't successfully negotiate a set of TLS parameters with your server won't be able to deliver mail to you. Be careful about selecting Require secure channel; if the volume of inbound mail subsequently drops, you might need to consider whether improved privacy is worth losing messages.
Troubleshooting TLS
After you turn on outbound TLS, keep an eye on your server queues. Some systems (primarily those running variants of UNIX Sendmail) will reject TLS connections from systems that use self-signed certificates, whereas others will accept STARTTLS, then won't complete the security negotiation for some other reason. If your server can't successfully negotiate a TLS connection and if it or the other system requires TLS, mail won't flow to that system.
If you see mail backing up to a particular destination system after you turn on TLS, you'll need to find out whether TLS failure is the cause. If it is, you'll need to determine why TLS is failing. Check the SMTP logs and the System and Application event logs for clues. If that doesn't help, contact the remote system's administrator.
If you still can't resolve the problem, you might be able to work around it. Although the Exchange SMTP engine doesn't support domain-specific TLS settings, you can create another SMTP virtual server that doesn't use TLS, then pair it with an SMTP connector. Set the connector's properties to include the domains that you're having trouble communicating with. Because Exchange always prefers a more specific route to a less specific one, mail bound for the specified destinations will be sent over that connector, and your mail will flow again.
Share:

How do you clear the DNS cache on Windows?

How do you clear the DNS cache on Windows?

  • ip /flushdns
  • ipconfig /flushdns
  • nslookup /flushdns
  • ipconfig /cleardns 


EXPLANATION

Your DNS cache stores the locations (IP addresses) of web servers that contain web pages which you have recently viewed. If the location of the web server changes before the entry in your DNS cache updates, you can no longer access the site.
If you encounter a large number of HTML 404 error codes, you may need to clear your DNS cache. After you clear your DNS cache, your computer will query nameservers for the new DNS information.

How to clear your DNS cache

The following methods allow you to remove old and inaccurate DNS information that may result in 404 errors.

Windows® 8

To clear your DNS cache if you use Windows 8, perform the following steps:
  1. On your keyboard, press Win+X to open the WinX Menu.
  2. Right-click Command Prompt and select Run as Administrator.
  3. Run the following command:
    ipconfig /flushdns
    If the command succeeds, the system returns the following message:
    Windows IP configuration successfully flushed the DNS Resolver Cache.

Windows® 7

To clear your DNS cache if you use Windows 7, perform the following steps:
  1. Click Start.
  2. Enter cmd in the Start menu search text box.
  3. Right-click Command Prompt and select Run as Administrator.
  4. Run the following command:
    ipconfig /flushdns
    If the command succeeds, the system returns the following message:
    Windows IP configuration successfully flushed the DNS Resolver Cache.

Windows XP®, 2000, or Vista®

To clear your DNS cache if you use Windows XP, 2000, or Vista, perform the following steps:
  1. Click Start.
  2. On the Start menu, click Run....
    • If you do not see the Run command in Vista, enter run in the Search bar.
  3. Run the following command in the Run text box:
    ipconfig /flushdns
    If the command succeeds, the system returns the following message:
    Successfully flushed the DNS Resolver Cache.

MacOS® 10.10.4 and above

To clear your DNS cache if you use MacOS X version 10.10.4 or above, perform the following steps:
  1. Click Applications.
  2. Click Utilities.
  3. Click Terminal.
  4. Run the following command:
    sudo killall -HUP mDNSResponder
    If the command succeeds, the system does not return any output.
    Warning:

    To run this command, you must know the computer's administrator account password.

MacOS 10.10.1, 10.10.2, and 10.10.3

To clear your DNS cache if you use MacOS X version 10.10 through 10.10.3, perform the following steps:
  1. Click Applications.
  2. Click Utilities.
  3. Click Terminal.
  4. Run the following command:
    sudo discoveryutil mdnsflushcache
    If the command succeeds, the system does not return any output.
    Warning:

    To run this command, you must know the computer's administrator account password.

MacOS 10.7, 10.8, and 10.9

To clear your DNS cache if you use MacOS X version 10.7, 10.8, or 10.9, perform the following steps:
  1. Click Applications.
  2. Click Utilities.
  3. Double-click Terminal.
  4. Run the following command:
    sudo killall -HUP mDNSResponder
    If the command succeeds, the system does not return any output.
    Warning:

    To run this command, you must know the computer's administrator account password.

MacOS 10.5 and 10.6

To clear your DNS cache if you use MacOS X version 10.5 or 10.6, perform the following steps:
  1. Click Applications.
  2. Click Utilities.
  3. Double-click Terminal.
  4. Run the following command:
    sudo dscacheutil -flushcache
    If the command succeeds, the system does not return any output.
    Warning:

    To run this command, you must know the computer's administrator account password.

 

Share:

Popular Posts