Windows Tips

AD-Powershell for Active Directory Administrators

noreply@blogger.com (DORNALA NAVEEN REDDY) — Wed, 18 Nov 2015 10:57:00 +0000

http://social.technet.microsoft.com/wiki/contents/articles/5819.ad-powershell-for-active-directory-administrators.aspx

Computer object commands

List all computer accounts in a domain

Get-ADComputer –Filter {Name –Like "*"}

View all computers that are logged in for 90 days to the Active Directory

Search-ADaccount -AccountInactive -Timespan 90 -ComputersOnly

OR

$lastLogon = (get-date).adddays(-90).ToFileTime()
Get-ADComputer -filter {lastLogonTimestamp -gt $lastLogon}
Find and delete all disabled Computer accounts in Active Directory

Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | Remove-ADComputer

Find and delete disabled computer accounts from a specific OU

Search-ADAccount -AccountDisabled -Searchbase "OU=IT,DC=Contoso,DC=Com" -ComputersOnly | Sort-Object | Remove-ADComputer

Find and delete all computer accounts that no longer have signed up since 11/20/2011 to the Active Directory

Search-ADAccount -AccountInactive -DateTime "20.11.2011" –ComputersOnly | Sort-Object | Remove-ADComputer
List only disabled Computer accounts in Domain
Search-ADAccount -AccountDisabled -ComputersOnly | Format-Table Name

Move Computer to other OU (example: Computer=CLIENT1 to OU=IT)

Get-ADComputer CLIENT1 | Move-ADObject -TargetPath "OU=IT,DC=Contoso,DC=Com"

See Computer account detail (example: Computer=CLIENT1)

Get-ADComputer -Filter {Name -Like "CLIENT1"}

Get a specific computer showing all the properties (example: Computer=CLIENT1)

Get-ADComputer "CLIENT1" -Properties *

List Computers (Name, Operating System, Service Pack, Operating System version)

Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto

Export Computers List (Name, Operating System, Service Pack, Operating Systemversion)to CSV File

Get-ADComputer -Filter * -Property * | Select-Object Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | Export-CSV AllWindows.csv -NoTypeInformation -Encoding UTF8

Get Computer IPv4 Address and DnsHostName

Get-ADComputer -Filter {Name -Like "Computer-Name"} -Properties IPv4Address | Format-List Name,DnsHostName,IPv4Address

Get all Computers in a specific OU (example: OU=IT, Domain=Contoso.com)

Get-ADComputer -SearchBase "OU=IT,DC=Contoso,DC=Com" -filter *

Get all the Computers without a specific DNS suffix

Get-ADComputer -filter "DnsHostName -notlike '*.Contoso.Com'"

Get Computer Service Principal Names (SPNs)

Get-ADComputer "Computer-Name" –Properties ServicePrincipalNames | Select-Object –Expand ServicePrincipalNames

Get Computers Security Identifiers (SIDs)

Get-ADComputer -Filter {Name -like "*"} | Select Name,SID | Format-Table -Auto

All computer accounts that were created in the last 90 days in the Active Directory

Get-ADComputer -Filter * -Properties whenCreated | ? { ((Get-Date) - $_.whenCreated).Days -lt 90} | Format-Table Name,WhenCreated,Name,DistinguishedName -Autosize -Wrap

All computer accounts that were created as of December 1, 2011 (12/01/2011) in the Active Directory

Get-ADComputer -LDAPFilter "(&(objectCategory=person)(whenCreated>=20111201000000.0Z))" -Properties whenCreated | Format-Table Name,whenCreated,distinguishedName -Autosize -Wrap

All computer accounts that were created here in a given time, between the 10/01/2011 and 12/01/2011 in Active Directory

$Start = Get-Date -Day 01 -Month 10 -Year 2011 -Hour 00
$End = Get-Date -Day 01 -Month 12 -Year 2011 -Hour 23 -Minute 59
Get-ADComputer -Filter * -Properties whenCreated | ? { ($_.whenCreated -gt $Start) -and ($_.whenCreated -le $End) } | Format-Table Name,WhenCreated,DistinguishedName -Autosize -Wrap

All computer accounts, Last Password Set in a given time, between the 10/01/2011 and 12/01/2011 in Active Directory
$Start = Get-Date -Day 01 -Month 10 -Year 2011 -Hour 00
$End = Get-Date -Day 01 -Month 12 -Year 2011 -Hour 23 -Minute 59
Get-ADComputer -Filter * -Properties PasswordLastSet | ? { ($_.PasswordLastSet -gt $Start) -and ($_.PasswordLastSet -le $End) } | Format-Table Name,WhenCreated,DistinguishedName -Autosize -Wrap

All computer accounts, Last Password Set in the last 90 days in Active Directory
$Date = (Get-Date).AddDays(-90)
Get-ADComputer -Filter * -Properties PasswordLastSet | where { $_.PasswordLastSet -le $Date } | Format-Table Name,PasswordLastSet,DistinguishedName -Autosize -Wrap

Group object commands

List all members of a group (example: Group=Experts)

Get-ADGroupMember Experts | Format-Table Name

All properties of a group (example: Group=IT)

Get-ADGroup IT -Properties *

List only Universal Security groups

Get-ADGroup –LDAPFilter "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483640))"

List only Global Security groups

Get-ADGroup –LDAPFilter "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483646))"

List only Domain Local Security groups

Get-ADGroup –LDAPFilter "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483644))"

List all Group memberships for a user (example: User=EdPrice)

Get-ADAccountAuthorizationGroup EdPrice

Move a Group to another OU (example: Group=Experts, Old-OU=IT, New-OU=Service, Domain=Contoso.com)

Move-ADObject "CN=Experts,OU=IT,DC=Contoso,DC=com" -TargetPath "OU=Service,DC=Contoso,DC=com"

Add members to a group (example: Group=Experts, User=EdPrice)

Add-ADGroupmember Experts -Member EdPrice

Delete Group (example: Group=Experts)

Remove-ADGroup Experts

Delete a User from a Group (example: Group=Experts, User=EdPrice)
Remove-ADGroupMember Experts -Member EdPrice

Set Description for a Group (example: Group=JoinPC, Description=This group is allowed join PCs to Domain)
Set-ADGroup JoinPC -Description "This group is allowed join PCs to Domain"

Add Users from one Group to another Group (example: from Group1=DataUsers to Group2=SQLUsers)
Get-ADGroupMember DataUsers | Select sAMAccountName | ForEach { Add-ADGroupMember SQLUsers -Members $_.sAMAccountName }
Comparing two Groups to see the Group memberships (example: Group1=Administratorso, Group2=DNSAdmins)
Compare-Object ( Get-ADGroupMember Administrators) ( Get-ADGroupMember DNSAdmins) -IncludeEqual

Organizational Unit (OU) commands

All OUs in Domain

Get-ADOrganizationalUnit -Filter {Name -like „*“} | FT Name, DistinguishedName -A

Create OU (example: OU=IT, Domain=Contoso.com)

New-ADOrganizationalUnit -Name IT -Path "DC=Contoso,DC=Com"

Contents of a specific OU (example: OU=IT, Domain=Contoso.com)

Get-ADObject -Filter {Name -Like "*"} -Searchbase "OU=IT,DC=Contoso,DC=Com"

Rename OU (example: Old-Name=IT, New-Name=Admin, Domain=Contoso.com)

Rename-ADObject "OU=IT,DC=Contoso,DC=Com" -NewName Admin

Delete OU including contents (example: OU=IT, Domain=Contoso.com)

Remove-ADOrganizationalUnit IT -Recursive

Delete user from specific OU (example: User=EdPrice, OU=IT, Domain=Contoso.com)

Remove-ADObject "CN=EdPrice,OU=IT,DC=Contoso,DC=Com"

Move all objects from one OU to another OU (example: Old-OU=IT, New-OU=Manager, Domain=Contoso.com)

Get-ADObject -Filter {Name -Like "*"} -Searchbase "OU=IT,DC=Contoso,DC=Com" -SearchScope OneLevel | Move-ADObject -TargetPath "OU=Manager,DC=Contoso,DC=Com"

User object commands

List all User accounts in the Domain

Get-ADUser –Filter *

List all User accounts in a specific OU (example: OU=IT, Domain=Contoso.com)

Get-ADUser –Filter * -Searchbase "OU=IT,DC=Contoso,DC=Com" | FT

List all User accounts from specific City (example: City=NewYork)

Get ADUser -Filter {city - like "NewYork"} | FT

List only disabled User accounts in Domain
Search-ADAccount –AccountDisabled –Usersonly | FT Name

List all User accounts whose First Name is Ed

Get-ADUser –Filter {givenName –Like "Ed"} | FT

List all User accounts whose Last Name is Price

Get-ADUser –Filter {Surname –Like "Price"} | FT

List all User accounts from the specific Department (example: Department=Support)

Get-ADUser –Filter {Department –Like "Support"} | FT

List a User's Group memberships (example: User=Richard)

Get-ADPrincipalGroupMembership -Identity Richard

List all Users from specific Group and move Users to another OU (example: Group=People, Target OU=NewYork, Domain=Contoso.com)

Get-ADGroupMember People -Recursive | Move-ADObject –TargetPath "OU=NewYork,DC=Contoso,DC=Com"

Remove all users in an OU from a specific Group (example: Group=People, OU=NewYork, Domain=Contoso.com)

$Users = Get-ADUser -Filter * -Searchbase "OU=NewYork,DC=Contoso,DC=Com"
Remove-ADGroupMember -Identity People -Member $Users -Confirm:0

How to add EBS volume to Linux machine in AWS

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 13 Oct 2015 15:53:00 +0000

1. Login to AWS console

2. Create 50 GB volume

3. Attach to the Linux instance

4. Login to the Linux server

5. After completing above step, now new volume will list your system. You can check this using ‘fdisk -l‘ command

6. Create a File system to newly added EBS volume with below command (In my case new disk is:/xvdj)

mkfs /dev/xvdj

7. Make a directory with below command (In my case directory name is "mountdriveE")

mkdir /mountdriveE

8. Mount this disk to mount point with below command

mount /dev/xvdj /mountdriveE

9. Add below entry at the end of file /etc/fstab for permanent

/dev/xvdj /mountdriveE ext4 defaults 1 1

How to Delete Files which exceed 255 Characters Without 3rd Party Tools

noreply@blogger.com (DORNALA NAVEEN REDDY) — Thu, 23 Jul 2015 10:03:00 +0000

create an empty folder on C:\ called test then used the mirror switch to copy the test folder to the HomeDrives folder.

robocopy /MIR c:\test D:\xxx\xxx\xxx

How do I find out what service is using a certain port?

noreply@blogger.com (DORNALA NAVEEN REDDY) — Thu, 09 Apr 2015 06:44:00 +0000

We have freeware tool "currports"

http://www.nirsoft.net/utils/cports.html

Seizing An Operations Master with NTDSUTIL in Windows Server 2008 R2

noreply@blogger.com (DORNALA NAVEEN REDDY) — Mon, 02 Mar 2015 08:01:00 +0000

http://www.msserverpro.com/seizing-an-operations-master-with-ntdsutil-in-windows-server-2008-r2/

In real network, when operations master server fails due to hardware issues or some other problems, we need to move the operation master role to another domain controller as soon as possible. This move process is called seizing. Therefore, Seizing an operations master role means forcing an operations master role onto another domain controller. Before we seize operations master roles, we must permanently disconnect the domain controller that holds the operations master roles from the network.

Here, all Operation Master Roles are on KTM-DC01-2K8 domain controller. In this scenario, currently this server is Offline due to hardware problems. So we get an error when we open Operations Masters roles on other domain controller KTM-DC02-2K8. To solve this problem, we have to seize Operations Masters roles and reassign it to KTM-DC02-2K8 domain controller as soon as possible.

Before KTM-DC01-2K8 become Offline, all Operations Masters Roles are in the KTM-DC01-2K8.

Use ntdsutil to perform this procedure:
1. Log on to KTM-DC02-2K8, working DC.

2. Open Command prompt, in the Run box, type cmd and then Click OK.

3. At the Command Prompt, type ntdsutil and press Enter.

4. At the ntdsutil prompt, type activate instance NTDS and press Enter.

5. At the ntdsutil prompt type roles and then press Enter.

6. At the fsmo maintenance prompt, type? and press Enter to see a list of available commands.

7. At the fsmo maintenance prompt, type connections and press Enter.

8. At the server connections prompt, type? and press Enter for the help Information.

9. At the server connections prompt, type connect to server followed by the fully qualified domain name (FQDN) of the domain controller that will be the new role holder, and then press Enter. Here FQDN will beKTM-DC02-2K8.msserverpro.com.

10. At the server connections prompt, type quit and press Enter.

11. At the fsmo maintenance prompt, type one of the following commands to seize the appropriate operations master and press Enter.
      i.) Seize infrastructure master
      ii.) Seize naming master
     iii.) Seize PDC
     iv.) Seize RID master
      v.) Seize schema master

12. At the fsmo maintenance prompt, type quit and then press Enter to gain access to the ntdsutil prompt.

13. At the ntdsutil prompt, type quit and then press Enter to quit the ntdsutil utility.

14. At the Command prompt, type netdom query fsmo to verify all the Operation Masters Roles in KTM-DC02-2K8.msserverpro.com.

Summary:

Seizing an Operations Master role is critical whenever the Primary Domain Controller is non-functional for business continuity. The above article outlines how to carry out the role seizing operations. I hope this helps.

Get Started with Ansible on the cloud

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 10 Feb 2015 08:01:00 +0000

http://cloudacademy.com/blog/get-started-with-ansible-on-the-cloud/?utm_content=buffer3e169&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

CONFIGURING TRUSTS – PART 4

noreply@blogger.com (DORNALA NAVEEN REDDY) — Mon, 02 Feb 2015 07:44:00 +0000

http://www.rebeladmin.com/2015/02/configuring-trusts-part-4/

This is the last part of the series which explain about “Trusts” between infrastructures. If you not checked the other 3 parts yet you can find them in here.

Configuring Trusts – Part 1
Configuring Trusts – Part 2
Configuring Trusts – Part 3

This article will explain how to configure trusts between infrastructures.

Demo Setup

For the demonstration I will be using following setup.

Organization	Domain	Primary DC
Contoso Ltd.	Contoso.com	Microsoft Windows Server 2012 R2
XYZ Ltd.	Xyz.com	Microsoft Windows Server 2012 R2

I am going to initiate a “Forest Trust” between the 2 organizations. It will be Two-Way trust which allows each forest, domains and users to access “allowed” resources in each organization infrastructure.

Before start the process the initial step is to make sure following ports are open in firewalls in both organizations to initiate the trusts.

UDP Port 88 – Kerberos Protocol
TCP and UDP Port 387 – LDAP
TCP Port 445 – Microsoft SMB
TCP Port 135 – Trust endpoint resolution

In order to initiate a trust you need to login as user account which is member of Domain Admins or Enterprise Admins groups.

Also you need to consider about the DNS ( domain name services )before proceed with the trust initiation process. If both organizations using root DNS server coming for both forests it will not be an issue. But if not you need to create DNS Zones in each forest dns servers. In here for the demo I have setup secondary dns zone with transferring copy of running DNS zone on XYZ.com. I have explain DNS zone setup in one of my previous articles in blog. If you not familiar with the process please refer to it here.

1) To start the process I will log in to contoso.com domain as enterprise administrator.

2) Then Server Manager > Active Directory Domains and Trusts

3) In active directory domains and trust snap-in right click on contoso.com domain and click properties

4) In next window go to “Trusts” tab and click on “New Trust” button

5) It will open the “New Trust Wizard” click next to start the process

6) In next window we need to specify the DNS name or the netbios name of the domain we going to initiate trust with. In our demo it will be “xyz.com”. then click next to continue

7) In next window we need to select the trust type. I have selected “Forest Trust” and click next to continue

8) We are going to setup “Two-Way” trust so in next window I selected “Two-way” from the list and click continue

9) Trusts are need to initiate in both sides. But if you have appropriate access permissions to the remote forest, you can initiate it. In next window it give option to initiate the trust in remote forest. Since I do have access I select “Both this domain and specified domain” and click next

10) In next window I have specified the logins to initiate trust in remote forest (the account need to be member of Domain Admins or Enterprise Admins groups). Then click next to continue

11) In next windows it ask to select the authentication scope for local forest. In here I select forest-wide authentication

12) In next windows it ask to select the authentication scope for remote forest. In here I select forest-wide authentication

13) In next window it gives brief description about the selections we made and click next to initiate the trust

14) In next window it asks about routed name suffixes for the local forest. I will use default and click next

15) In another window it asks to confirm the outgoing trust. Since we initiated the other side of trust, select yes and click next

16) Next window it asks to confirm incoming trust. Since we initiated the other side of trust, select yes and click next

17) Then it gives confirmation about the successfully create trust. Click finish to exit from wizard.

18) In remote XYZ.com we can confirm the initiate trust by looking in to domain properties like we did in steps 1-3

This completes the process of creating forest-trust. The options selected on process will change based on trust type, authentication scope etc.

Testing

For the testing purpose of the trust I have created following scenario.

Contoso domain file server hosts a folder called “Share-Contoso”. We need to provide access to user account called “xyz-user” from XYZ forest to this particular folder.

After initiating the trust, when we going to apply share permission to the “Share-Contoso” folder now we can select users from the XYZ.com domain.

After applying permissions I am trying to log in to contoso file server from remote location ( here I used a pc which is not added to domain ) and once its ask to provide logins I have provided the login info for xyz-user for XYZ.com domain.

Once it’s authenticated we can see it’s provided the access to relevant share.

As we can see the trust is successfully initiated.

CONFIGURING TRUSTS – PART 3

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 27 Jan 2015 07:27:00 +0000

http://www.rebeladmin.com/2015/01/configuring-trusts-part-3/

This is the part 3 of the series which explain about “Trusts” between infrastructures. If you not checked the other 2 parts yet you can find them in here.

Configuring Trusts – Part 1
Configuring Trusts – Part 2

In this article I will cover up the rest of the concepts, terms, involves with setting up a trust.

Security Identifier (SID) filtering

Microsoft Systems uses a structure known as SID to express its identities. Its act as a token. SID filtering is used to block users in trusted forest or domain being able to elevate their privileges in local forest or domain. This is important for external trusts as when you trusting you can control rights to provide credentials between domains.

By default windows 2012, windows 2012 R2 have SID filtering enabled. If you wish to disable this, you can do it using following commands. (https://technet.microsoft.com/en-us/library/cc794801(v=ws.10).aspx)

To disable SID filter quarantining for the trusting domain

Netdom trust /domain: /quarantine:No /userD: /passwordD:

To disable SID filter quarantining for the trusting forest

Netdom trust /domain: /enablesidhistory:Yes /userD: /passwordD:

It is recommended to keep the default enabled state unless you have critical reason.

Name Suffix Routing

In an organization it may have different UPN (User Principle Name) suffixes used with in its forest. For example Contoso LTD. May use contoso.com, mycontoso.net, companyA.org as name suffixes. But when you creating a trust you may not need to allow users from all these suffixes. With Name suffix routing we can enable or disable the UPN suffixes which will involve with the trust operations.

I will demonstrate how we can do this in next post which will go more in to real world configurations.

Trust Authentications

Trusts can use 2 authentication protocols. By default it uses Kerberos Version 5. If it’s not supporting it use NTLM Authentication. In order to initiate a trust, the administrator need to be a member of domain admin group or enterprise admin user group. Trust needs to initiate in both sides.

Trust Components (https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx)

Before initiate trusts it is important to make sure following ports are open in both sides.

UDP Port 88 – Kerberos Protocol
TCP and UDP Port 387 – LDAP
TCP Port 445 – Microsoft SMB
TCP Port 135 – Trust endpoint resolution

This is the end of a part 3 of the configuring trust series and in next article let’s look in to real world setups

CONFIGURING TRUSTS – PART 2

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 27 Jan 2015 07:26:00 +0000

http://www.rebeladmin.com/2015/01/configuring-trusts-part-2/

This is the part 2 of the series of articles which describes about trusts between infrastructures. If you still not read the part 1 of the series you can find it in here.

On previous article I explain what is a trust and common terms used in process. This article will be extend to it.

External Trusts – Let’s assume we have child domain called “HQ.contoso.com” under contoso.com forest. Company recently had business relationship with XYZ corp. They having child domain under the XYZ.com forest called “Sales.xyz.com”. As per business need management wants to allow users, resources in “Sales.xyz.com” to access data, resources in “HQ.contoso.com”. None of the other domains, child domains in both forest should allow in this operation. This is where we can use “External Trusts”. So it will only allow part of the forest to participate in unique operation.

Realm Trust – Also in real world Microsoft AD services is not the only directory services organizations uses. So it is not practical forcing another organization to change their directory services to match with ours to make trust. Realm trusts are helps to mitigate this issue and it allows to make trusts with active directory domain and non-Windows Kerberos version 5 realm(such as Linux directory service)

Forest Trusts – This is the most commonly used trust type. Using forest trust, one active directory forest will trust another active directory forest. These trust can be uni-directional trust or bi-direction trusts. By default forest trusts are “Trasitive”. It means any domain or child domain under these forests will be automatically trusted by each other (based on trust direction).

In forest trust we can use two authentication scopes according to our business requirement.

Forest-wide Authentication – This is the default authentication setting for forest trusts. Users in remote forest will be automatically allow to authenticate local forest resources. In here it doesn’t means any user in remote forest can access any resources. They still need pass the ACL, permission rules resources used. This authentication model is recommended for the organizations with multiple forests.

Selective Authentication – Using this method we can allow selected users, groups in remote forest to access resources in local forest. This is the best option to control access security while maintaining a forest trust.

Shortcut Trusts – Let’s assume we have two forests called contoso.com and XYZ.com. As per below image both forests do have several domains and child domains. We do have a user called ‘User A” in “IT.Hotels.contoso.com”. He needs to access a file share from a server located under “HR.Constructions.XYZ.com”.

Now if we think about the authentication process it will need to pass the traffic all the way up to root domain in both forests. Sometime these child domains may located on different countries or cities. These may also connect through slow links due to high cost. So this traffic does effect regular operations.

Shortcut trusts allows to pass authentication traffic between IT.Hotels.contoso.com and HR.Constructions.XYZ.com directly without going through domain tree. Shortcut trust can be bi-directional or uni-directional.

This is the end of Part 2 of the series

CONFIGURING TRUSTS – PART 1

noreply@blogger.com (DORNALA NAVEEN REDDY) — Fri, 23 Jan 2015 10:49:00 +0000

http://www.rebeladmin.com/2015/01/configuring-trusts-part-1/

Trusts, simply we can define as a bond between multiple domains, multiple forests. It controls how or what been allowed between domains and forests.

Let’s assume we have a company called Contoso Inc. and its running with domain contoso.com. Company recently merge with another company called XYZ Inc. and its running with domainxyz.com. Management wants to allow their resources to been used by both company users. For ex- A user in contoso.com will required to access a share in xyz.com file server. Company wants to do it with minimum impact or changes. This is where “trusts” comes in to the picture. Using trusts we can control who will be trusted, how it will be and what sort of access users have on resources.

Before we move in to the configurations it is important to understand the concepts of trusts.

Trusting Domain – This will be the domain contains the resources which will need to allow access. As ex- in my domain contoso.com have a file share called “Sales”. I needs to allow sales users from XYZ.com to access it. In here contoso.com act as trusting domain.

Trusted Domain – This will holds the resources which you wish to grant access. As ex- if we take same above example, XYZ.com domain holds the user accounts which will be allow to access resources on contoso.com. So XYZ.com act as trusted domain.

Transitivity – Trust transitivity allows to extend the trust in to child domain level. For example with trust I may need to allow users in child domains of xyz.com also to have access in to contoso.com domain resources. I can do it with trust transitivity.

We can categorize trusts based on the direction it’s applying to.

Two-Way Trust – This also known as bidirectional trust. This is the trust mostly been used among organizations. In here both sides on the trust work as trusting and trusted domains.

One-way Incoming Trust – In here trust is created in trusted domain and trusted domain can access resources in trusting domain only.

One-way Outgoing Trust – In here resources in remote, specified domain can authenticated in initiating domain.

Embedding IAM roles in EC2 instances

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 30 Dec 2014 05:34:00 +0000

http://searchaws.techtarget.com/tip/Embedding-IAM-roles-in-EC2-instances

Many enterprises know that turning off unused AWS instances can save money. But not all IT pros know which method is best and how to set it up.

There are a few ways to turn off unused Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instances. If you don't use Auto Scaling, you will need to configure this process manually. One method is to use command-line interface (CLI) tools ec2-start-instances and ec2-stop-instances on Linux, using either a role-based method or an identity access management user-credential method.

Setting up role-based security enables you to associate AWS identity and access management (IAM) roles with the instance, without having to manually add plain-text security credentials. This not only improves security, but is easier to manage. Identify an instance that will perform CLI start and stop scripts, or create a dedicated micro-instance to perform these maintenance tasks.

IAM roles cannot be embedded in instances that have been created; they must be defined during the setup phase. This tip walks you through the instance configuration process needed to run CLI commands based on IAM roles.

Setting up role-based security on an EC2 instance

To configure cron to turn AWS EC2 instances on or off, create a specific security role and embed this role in a fresh EC2. Follow these steps to create the security role:

From the AWS Management Console, click IAM -- Secure AWS Access Control and then Roles and then select Create a New Role.
Enter ec2-privs-for-cron (or any unique name you choose) and click Next Step.
Hit Select, which is found next to the Amazon EC2 - Allows EC2 instances to call AWS services on your behalf role description. Select theNext Step button.
Click on Policy Generator and hit Select next to the Use the policy generator to create your own set of permissions text.
In the policy generator interface, check that Allow is selected and chooseAmazon EC2 from the Amazon Service dropdown list. Then click Actionsand StartInstances, followed by StopInstances. Enter an Amazon Resource Name (ARN): arn:aws:ec2:*:*:*", and click Next Step.

This will bring you to a screen showing the new policy as:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1413912997000",
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:*:*:*"
]
}
]
}

Review the Role Name, Role ARN and the Trusted Entities, and click Create Role and then Done. You can now attach the new role, which is called "ec2-privs-for-cron," to a new EC2.

Next, spin up new EC2 instance. To do so, launch a new Amazon Machine Instance (AMI), which comes preinstalled with the AWS CLI tools. For this scenario, we'll choose the default instance settings. If you spin up a non-AMI Linux instance, you should install the AWS Command Line Interfacesoftware.

Select the ec2-privs-for-cron role In the Configure Instance Details page of the IAM role field. You won't be able to change the IAM role once the instance is launched. The AWS access keys with the specified permissions of this role will be available to this EC2 instance automatically. Ensure you can Secure Socket Shell (SSH) into the instance to complete the configuration. Finally, click Launch Instance.

Configure the EC2 instance

To configure the new instance, SSH into the instance and create EC2 start / stop scripts. Then create a directory, such as "scripts," in the home ec2-user account.

Pro+
Features
Enjoy the benefits of Pro+ membership, learn more and join.

E-Handbook
Getting started with AWS EC2 instances
Change directory into the scripts directory and create a "stop-ec2.sh" script file; add the "ec2-stop-instances i-xxxxxxxx" AWS CLI command where "i-xxxxxxxx" is the instance ID you want to stop. Repeat the CLI for each instance you want to stop.

Next, create a second script file named "start-ec2.sh" and add the "ec2-start-instances i-xxxxxxxx" AWS CLI where "i-xxxxxxxx" is the instance ID you want to start. Next, ensure the execute bit is set on these scripts. Add cron entries.

Edit the crontab file using the "crontab –e" command and add the follow lines:

EC2_HOME = /opt/aws/apitools/ec2-1.7.1.1 -- This must be the actual AWS CLI root directory; it cannot reference a symbolic directory name.
JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64 -- This must be the actual JAVA root directory; it cannot reference a symbolic directory name.
PATH=/bin:/usr/bin:/opt/aws/apitools/ec2-1.7.1.1/bin -- The PATH environment variable containing the bin directories of any executables used in cron script files must be part of the path.
"30 2 * * * /home/ec2-user/scripts/stop-ec2.sh >> /tmp/aws_instance_stop.log 2>&1" -- This is the actual cron entry that executes the stop-ec2.sh scipt. The first five parameters define the date/time and frequency the script is to be run; cron uses the time zone predefined in the instance. As such, since my instance is set to the UTC time zone, the entry states the stop-ec2.sh script will run every day at 2:30 a.m. UTC or 10 p.m. EST.
Reference the cron wiki to learn how to set different date and time frequencies. The ">> /tmp/aws_instance_stop.log" logs the results of script execution to the aws_instance_stop.log file in the /tmp directory.
"15 10 0 0 * /home/ec2-user/scripts/start-ec2.sh >> /tmp/aws_instance_start.log 2>&1" This is the actual cron entry that executes the start-ec2.sh scipt. Notes: cron will execute this start-ec2.sh script every day at 10:15 a.m. UTC or 6:15 a.m. EST.
The ">> /tmp/aws_instance_start.log" logs the results of script execution to the aws_instance_start.log file in the /tmp directory.
Your crontab file should now look something like this:
# cron entries for starting/stopping EC2 instances (rjv) 10.21.2014
# Set Environment Variables
EC2_HOME=/opt/aws/apitools/ec2-1.7.1.1
JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
PATH=/bin:/usr/bin:/opt/aws/apitools/ec2-1.7.1.1/bin

# define scripts to run based on schedule
30 2 * * * /home/ec2-user/scripts/stop-ec2.sh > /tmp/aws_instance_stop.log 2>&1
15 10 * * * /home/ec2-user/scripts/start-ec2.sh > /tmp/aws_instance_start.log 2>&1

How to configure a firewall for domains and trusts

noreply@blogger.com (DORNALA NAVEEN REDDY) — Mon, 29 Dec 2014 10:11:00 +0000

http://support.microsoft.com/kb/179442

Interforest Migration with ADMT 3.2

noreply@blogger.com (DORNALA NAVEEN REDDY) — Mon, 08 Dec 2014 07:50:00 +0000

http://social.technet.microsoft.com/wiki/contents/articles/11996.interforest-migration-with-admt-3-2-part-1.aspx

http://social.technet.microsoft.com/wiki/contents/articles/16208.interforest-migration-with-admt-3-2-part-2.aspx

http://social.technet.microsoft.com/wiki/contents/articles/16621.interforest-migration-with-admt-3-2-part-3.aspx

Installing Nagios 4 on Ubuntu 14 04 LTS

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 18 Nov 2014 18:11:00 +0000

Configuring A NAT Instance in AWS VPC

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 28 Oct 2014 12:25:00 +0000

The operation failed The specified user already exists

noreply@blogger.com (DORNALA NAVEEN REDDY) — Thu, 23 Oct 2014 13:37:00 +0000

Exact Error: the operation failed because the attempt to join this computer to the domain failed the specified account already exists

Solution: In my existing AD, I went under "Domain Controllers" OU and saw an entry of the host name of the second DC that i have been unsuccessfully attempted before. I deleted/demoted the second DC from the entry, and went back to the second DC and re-initiated the DCPROMO. It is now completing the wizard.

Active Directory replication between two sites which we have connectivity (VPN)

noreply@blogger.com (DORNALA NAVEEN REDDY) — Wed, 22 Oct 2014 13:00:00 +0000

reboot server remotely from command prompt

noreply@blogger.com (DORNALA NAVEEN REDDY) — Wed, 15 Oct 2014 12:11:00 +0000

1: SHUTDOWN /r /f /t 0 /m \\ /c ""

/r Shutdown and restart the computer.

/f Force running applications to close without forewarning users.

/t xxx Set the time-out period before shutdown to xxx seconds.
The valid range is 0-600, with a default of 30.

/m \\computer Specify the target computer.

/c "comment" Comment on the reason for the restart or shutdown.

If it got struck in the middle use below command to force restart: taskkill /s \\ServerIpAddress /im lsass.exe

Remote desktop session is getting frequently disconnected in VPC Public subnet

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 14 Oct 2014 06:24:00 +0000

Below are a list of possibly reasons this could be happening:

Influx of ingress and egress traffic could overwhelm the network card -Extended CPU load could overwhelm the system -Windows updates are missing

I recommend is to create another Network Interface for your instance for the sole purpose of Remote Desktop Connections -- use the other Network Interface for normal web traffic, this may help reduce the load. 1. Create an Elastic IP 2. Create a Network Interface (for RDP) with the same Subnet ID and VPC ID of your instance 3. Associate the Elastic IP with your new Network Interface 4. Assign the new Network Interface to your instance 5. Reboot 6. Use the Elastic IP for RDP connections only (Make sure security groups are correct)

Autoscalling Windows servers in AWS

noreply@blogger.com (DORNALA NAVEEN REDDY) — Tue, 16 Sep 2014 08:09:00 +0000

Steps for using the Amazon Command Line Tools:

Pre-requisites
All of the steps below can be skipped if you use EZAutoScaling.
Download the command line tools for Auto Scaling
Download the command line tools for CloudWatch
Set up Auto Scaling command line
Set up CloudWatch command line
Create new Launch Configuration
Create new Auto Scaling Group
Create per region
Create CloudWatch monitor to increase servers
Create CloudWatch monitor to decrease servers
Set Desired Capacity after creation
Monitoring your Auto Scaling Froups
Monitoring your Instances' health
Delete Auto Scaling Groups and Launch Configurations

Pre-requisites

You need to know which Amazon region (e.g. 'US East (N. Virginia)' or 'us-east-1') you want to set up your Auto Scaling in.
You need to have an AMI set up in that region. The AMI will be the image that will be used for each new instance in your Auto Scaling group.
You need to have a load balancer created in that region. Each new instance in the Auto Scaling group will be added to that load balancer.

Knowing your region
The region where your EC2 instances will be created can be viewed in the top-right corner of your AWS Management Console.

Having an AMI
Under the Services tab select EC2 and then click on AMIs in the left panel. In the right panel you need to have an AMI. If you don't have one then you need to create one. Every new Auto Scaling EC2 instance that is created will be an exact copy of this AMI.

Having a load balancer
Similarly to AMIs, the left panel has a link for Load Balancers. You need to create at least 1 load balancer. Every new Auto Scaling EC2 instance will be added to this load balancer. When you first create the load balancer, you don't need to attach any instances to it.

FYI: All of the steps below are converted to a web-based interface in EZAutoScaling's online tool. If you use EZAutoScaling you will not need to execute any of the steps below.

Download the command line tools for Auto Scaling

This is probably one of the easier steps in this guide. Click on this link and download the command line tools for Auto Scaling.

Download the command line tools for CloudWatch

Similarly to the step above, click on this link and download the command line tools for CloudWatch.

Set up Auto Scaling command line

After you unzip the command line tools to a directory, go that that directory. Setting up the command line is described in the file README.TXT.
There are quite a few pre-requisites to make this work, but the assumption for this guide is that you have the JAVA pre-requisites; you just need to set up the security keys to get the command line to work.

Here are the steps as per the README file:
1. Ensure that JAVA version 1.5 or higher is installed on your system: (java -version) [Assumption is that this is set up]
2. Unzip the deployment zip file [Assumption is that this is done]
3. Set the following environment variables:
3.1 AWS_AUTO_SCALING_HOME - The directory where the deployment files were copied to.

For Windows users to go: Start > right-click on My Computer > Properties
Click on Change Settings
Click on the Advanced tab and then Environment Variables
Add a new system variable with name "AWS_AUTO_SCALING_HOME" and the value where you unzipped the directory

3.2 JAVA_HOME - Java Installation home directory [Assumption is that this is set up]
4. Add "%AWS_AUTO_SCALING_HOME%\bin" to your path (Windows)

Open the variable "Path" and add "%AWS_AUTO_SCALING_HOME%\bin" at the end of the value. Make sure you add ";" between values.

Configuration of security keys; this guide will demonstrate how to set up the AWS keys with a credentials file:
1. Create your credentials file

Copy and paste the file "credential-file-path.template" that is in the unzipped directory.
Rename it to "credentials-yourname.template"
Open the copied file and write in it: AWSAccessKeyId=youaccesskeySecretKey=yoursecuritykey. Note that there are no spaces.
These two keys can be found in your AWS Management Console...
Click on your username in the top-right corner and then click on My Account
In the left navigation select "Security Credentials"
You will find the AWS Access Key and Secret Key on this page.

2. Set up the environment variable to the credentials file

Similarly to the steps above, add a new system environment variable with name "AWS_CREDENTIAL_FILE" and the value should be the path to the credentials file you created.

3. Finally, to check you have set up everything properly:

Open command prompt and go to the directory where you unzipped the Auto Scaling tools.
Go to the bin directory
Type as-describe-auto-scaling-groups --headers and you should see a result be returned that is not an error.

Set up CloudWatch command line

Setting this up is extremely similar to setting up Auto Scaling.

After you unzip the command line tools to a directory, go that that directory. Setting up the command line is described in the file README.TXT.
There are quite a few pre-requisites to make this work, but the assumption for this guide is that you have the JAVA pre-requisites; you just need to set up the security keys to get the command line to work.

Here are the steps as per the README file:
1. Ensure that JAVA version 1.5 or higher is installed on your system: (java -version) [Assumption is that this is set up]
2. Unzip the deployment zip file [Assumption is that this is done]
3. Set the following environment variables:
3.1 AWS_CLOUDWATCH_HOME - The directory where the deployment files were copied to.

For Windows users to go: Start > right-click on My Computer > Properties
Click on Change Settings
Click on the Advanced tab and then Environment Variables
Add a new system variable with name "AWS_CLOUDWATCH_HOME" and the value where you unzipped the directory (see screenshots from Auto Scaling steps).

3.2 JAVA_HOME - Java Installation home directory [Assumption is that this is set up]
4. Add "%AWS_CLOUDWATCH_HOME%\bin" to your path (Windows)

Open the variable "Path" and add "%AWS_CLOUDWATCH_HOME%\bin" at the end of the value. Make sure you add ";" between values.

Configuration of security keys; this guide will demonstrate how to set up the AWS keys with a credentials file:
1. Create your credentials file

Copy and paste the file "credential-file-path.template" that is in the unzipped directory.
Rename it to "credentials-yourname.template"
Open the copied file and write in it: AWSAccessKeyId=youaccesskeySecretKey=yoursecuritykey. Note that there are no spaces.
These two keys can be found in your AWS Management Console...
Click on your username in the top-right corner and then click on My Account
In the left navigation select "Security Credentials"
You will find the AWS Access Key and Secret Key on this page.

2. Set up the environment variable to the credentials file:

If you set up the Auto Scaling tools then you have already done this step.... Add a new system environment variable with name "AWS_CREDENTIAL_FILE" and the value should be the path to the credentials file you created (see screenshots from Auto Scaling steps).

3. Finally, to check you have set up everything properly:

Open command prompt and go to the directory where you unzipped the CloudWatch tools.
Go to the bin directory
Type mon-list-metrics --headers and you should see a result be returned that is not an error.

Create new Launch Configuration

The first step in creating an Auto Scaling group is to create a launch configuration for each new instance in the Auto Scaling Group.
To create a launch configuration:

Go to the Auto Scaling Command Line Tools BIN directory.
Use the command:
as-create-launch-config Launch Config Name --image-id AMI ID --instance-type Instance Size --key Security Key
- Launch Config Name: This is the name that you want to give to the launch configuration.
- AMI ID: This is the ID of the existing AMI (which was a pre-requisite).
- Instance Size: The size of each new instance, for example t1.micro. Sizes are listed here (see the API names).
- Security Key: The security key that should be applied to each new instance.
- Example: as-create-launch-config lc1 --image-id ami-12345678 --instance-type c1.xlarge --key securitykey1

The command can get much more detailed than the above, however as a start the above is sufficient.

Create new Auto Scaling Group

The auto scaling group says which launch configuration to use, what region, and which load balancer.
To create an auto scaling group:

Go to the Auto Scaling Command Line Tools BIN directory.
Use the command:
as-create-auto-scaling-group Auto Scaling Group Name --launch-configuration Launch Configuration Name --availability-zones Availability Zones --min-size Minimum size of group --max-size Maximum size of group --desired-capacity Starting desired capacity --load-balancers Load Balancers to add each new instance to
- Auto Scaling Group Name: Name of the new auto scaling group.
- Launch Configuration Name: Name of the launch configuration created previously.
- Availability Zones: The availability zones of the new EC2 instances that will be created. The zones are here. The zones you select for your new EC2 instances should be allowed by the load balancer that will be used.
- Minimum size of group: The minimum size of this group. If triggers get fired to reduce the size of the group, it will never go below this number.
- Maximum size of group: The maximum size of this group. If triggers get fired to increase the size of the group, it will never go above this number.
- Starting desired capacity: The number of EC2 instances to be started immediately.
- Load Balancers to add each new instance to: The load balancers to which each new EC2 instance should be added.
- Example: as-create-auto-scaling-group as-group1 --launch-configuration lc1 --availability-zones us-east-1a --min-size 1 --max-size 50 --desired-capacity 1 --load-balancers lb1

The command can get much more detailed than the above, however as a start the above is sufficient. After the above command runs, wait a few seconds and you should see new EC2 instances being created in your AWS Management Console. In the screenshot above the desired starting capacity was 1, therefore 1 new EC2 instance should start getting created.

Also make sure when you set this up that you test it - you need to make sure that each EC2 instance that is added to the Load Balancer is added and becomes "InService" in the load balancer. If it is "OutOfService" in the load balancer then the Health Check that the load balancer does is failing. This means that no requests will be routed to that EC2 instance.

Create per region

Auto Scaling is region specific. Below is a screenshot of regions in which you can create EC2 instances, and consequently independent Auto Scaling Groups:

Therefore, if you want to have EC2 instances in 2 different regions, you need to create an Auto Scaling Group for each region (i.e. 2 Auto Scaling Groups).

To create Auto Scaling groups in different regions you need to add an extra parameter to the commands that you write. Every single command needs to have --region Region API Name, for example --region us-west-1.

The Launch Configuration creation command would be:

as-create-launch-config lc1 --image-id ami-12345678 --instance-type c1.xlarge --key securitykey1 --region us-west-1

The Auto Scaling Group creation command would be:

as-create-auto-scaling-group as-group1 --launch-configuration lc1 --availability-zones us-east-1a --min-size 1 --max-size 50 --desired-capacity 1 --load-balancers lb1 LoadBalancer --region us-west-1

Create CloudWatch monitor to increase servers

The next important steps is to add a CloudWatch monitor so that if something occurs (such as CPU usage is too high on an EC2 instance) then a new EC2 instance will spawn in an Auto Scaling Group automatically.
Thanks to CardinalPath for the easy examples.

The steps are:

Go to the CloudWatch Command Line Tools BIN directory.
Create a policy:
as-put-scaling-policy --auto-scaling-group Auto Scaling Group Name --name Policy Name --adjustment Number of Servers --type ChangeInCapacity --cooldown 600
- This command will increase the auto scaling group by "Number of Servers" and will not run this policy more than once in 600 seconds.
- Auto Scaling Group Name: The name of the auto scaling group that will have another instance added.
- Policy Name: The name of this new policy that you are creating.
- Number of Servers: The number of servers that should be spawned when this policy executes.
The result of the above command will be an ID that looks like this: arn:aws:autoscaling:us-east-1:123123123123:scalingPolicy:aaa11aa2-11aa-1a11-1115-a111a111a111:autoScalingGroupName/AutoScaling:policyName/policy. Remember this.
Create the alarm that should trigger the policy:
mon-put-metric-alarm "Policy Name" --comparison-operator "GreaterThanThreshold" --evaluation-periods 3 --metric-name CPUUtilization --namespace AWS/EC2 --period 60 --statistic Average --threshold 70 --alarm-actions Policy Result --dimensions "InstanceId=Instance ID to monitor"
- This command will create a monitor which when "alarmed" will trigger the policy specified. The parameters say the this should monitor the Average CPU Utilization of the EC2 instance for every 60 seconds. If in 3 such measurements it is greater than 70% then trigger the policy specified in the previous command.
- Policy Name: The name of policy that you created with the previous command.
- Policy Result: The ID that resulted from the previous command.
- Instance ID to monitor: The command needs the ID of the EC2 instance for which it will monitor the CPU. This is usually the first instance in the auto scaling group.

Create CloudWatch monitor to decrease servers

In the previous step you set up EC2 instances to automatically get created. This step sets up CloudWatch monitors to terminate EC2 instances in an Auto Scaling group.
Thanks to CardinalPath for the easy examples.

The steps are:

Go to the CloudWatch Command Line Tools BIN directory.
Create a policy:
as-put-scaling-policy --auto-scaling-group Auto Scaling Group Name --name Policy Name "--adjustment=-1" --type ChangeInCapacity --cooldown 600
- This command will decrease the auto scaling group by -1 and will not run this policy more than once in 600 seconds.
- Auto Scaling Group Name: The name of the auto scaling group that will have an instance removed.
- Policy Name: The name of this new policy that you are creating.
The result of the above command will be an ID that looks like this: arn:aws:autoscaling:us-east-1:123123123123:scalingPolicy:aaa11aa2-11aa-1a11-1115-a111a111a111:autoScalingGroupName/AutoScaling:policyName/policy. Remember this.
Create the alarm that should trigger the policy:
mon-put-metric-alarm "Policy Name" --comparison-operator "LessThanThreshold" --evaluation-periods 3 --metric-name CPUUtilization --namespace AWS/EC2 --period 60 --statistic Average --threshold 20 --alarm-actions Policy Result --dimensions "InstanceId=Instance ID to monitor"
- This command will create a monitor which when "alarmed" will trigger the policy specified. The parameters say the this should monitor the Average CPU Utilization of the EC2 instance for every 60 seconds. If in 3 such measurements it is less than 20% then trigger the policy specified in the previous command.
- Policy Name: The name of policy that you created with the previous command.
- Policy Result: The ID that resulted from the previous command.
- Instance ID to monitor: The command needs the ID of the EC2 instance for which it will monitor the CPU. This is usually the first instance in the auto scaling group.

Set Desired Capacity after creation

There are many commands in the Auto Scaling command line tool package that allow you to edit an Auto Scaling Group. One most common usage is editing the number of EC2 instances that should be live currently. This is called "setting the desired capacity". To change the desired capacity do the following:

Go to the Auto Scaling Command Line Tools BIN directory.
Use the command:
as-set-desired-capacity Auto Scaling Group Name --desired-capacity Number of EC2 servers currently desired
- Auto Scaling Group Name: The name of the auto scaling group that you wish to edit.
- Number of EC2 servers currently desired: A number specifying the number of EC2 servers you would like to be currently live
- Example: as-set-desired-capacity as-group1 --desired-capacity 2

You should see the changes take effect a few seconds later. With the above command my auto scaling group had 1 instance and the command just added a 2nd.

Monitoring your Auto Scaling Groups

There are a few ways to see how the Auto Scaling groups are doing in terms of health and status. The easiest is the following command:

Go to the Auto Scaling Command Line Tools BIN directory.
Use the command:
as-describe-auto-scaling-groups --headers

This command will list all your Auto Scaling Groups for your default region (or you can specify the region parameter for another region), with headers, and it will also list all of the instances in that Auto Scaling Group.

Monitoring your Instances' health

There is no command line method to map Auto Scaling Groups and their instances to health information (such as CPU%) about the instances. You will need to remember or find out which EC2 instances make up your Auto Scaling Group and then check the health either through the AWS Management Console or using CloudWatch Command Line tools for those particular instances.

For example, you will need to find each EC2 instance that makes up your Auto Scaling Group and then use AWS Management Console to check up on its health as in the screenshot below:

On a side note, this is an area where EZAutoScaling is useful because it adds this mapping of EC2 Instances to Auto Scaling Groups and provides EC2 health information on one screen.

Delete Auto Scaling Groups and Launch Configurations

Deleting an Auto Scaling Group means first deleting the group (which terminates the EC2 instances of that group) and then deleting the Launch Configuration. If you have CloudWatch monitors attached, you can delete those separately through the AWS Management Console - they will simply stop monitoring and alerting. The steps to delete are:

Go to the Auto Scaling Command Line Tools BIN directory.
Use the command:
as-delete-auto-scaling-group Name of Auto Scaling Group --force-delete
- This deletes the group and forces the termination of EC2 instances.
Use the command:
as-delete-launch-config Launch Configuration Name –force

You should soon see the EC2 instances being terminated.

Summary

Let's quickly summarize the steps and commands needed to auto scale:

Make sure you have pre-requisites ready
Install and setup Auto Scaling Command Line Tools
Install and setup CloudWatch Command Line Tools
Create new launch configuration:
- as-create-launch-config Launch Config Name --image-id AMI ID --instance-type Instance Size --key Security Key
Create new auto scaling group:
- as-create-auto-scaling-group Auto Scaling Group Name --launch-configuration Launch Configuration Name --availability-zones Availability Zones --min-size Minimum size of group --max-size Maximum size of group --desired-capacity Starting desired capacity --load-balancers Load Balancers to add each new instance to
Create new CloudWatch monitor to scale up:
- as-put-scaling-policy --auto-scaling-group Auto Scaling Group Name --name Policy Name --adjustment Number of Servers --type ChangeInCapacity --cooldown 600
- mon-put-metric-alarm "Policy Name" --comparison-operator "GreaterThanThreshold" --evaluation-periods 3 --metric-name CPUUtilization --namespace AWS/EC2 --period 60 --statistic Average --threshold 70 --alarm-actions Policy Result --dimensions "InstanceId=Instance ID to monitor"
Create new CloudWatch monitor to scale down:
- as-put-scaling-policy --auto-scaling-group Auto Scaling Group Name --name Policy Name "--adjustment=-1" --type ChangeInCapacity --cooldown 600
- mon-put-metric-alarm "Policy Name" --comparison-operator "LessThanThreshold" --evaluation-periods 3 --metric-name CPUUtilization --namespace AWS/EC2 --period 60 --statistic Average --threshold 20 --alarm-actions Policy Result --dimensions "InstanceId=Instance ID to monitor"
Change desired capacity:
- as-set-desired-capacity Auto Scaling Group Name --desired-capacity Number of EC2 servers currently desired
Delete auto scaling group:
- as-delete-auto-scaling-group Name of Auto Scaling Group --force-delete
- as-delete-launch-config Launch Configuration Name –force

Or, don't bother with all of these commands and instead sign up for EZAutoScaling.

Resource: https://www.ezautoscaling.com/AutoScalingGuide.aspx

Unable to find a default server with Active Directory Web Services running

noreply@blogger.com (DORNALA NAVEEN REDDY) — Fri, 12 Sep 2014 11:11:00 +0000

Install .Net Framework 3.5 Sp1
Need to install hotfix: http://support.microsoft.com/kb/969429
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=20556
Install Active directory management gateway service (Windows6.0-KB968934) from http://www.microsoft.com/en-us/download/details.aspx?id=2852

Create a list of local administrators with PowerShell

noreply@blogger.com (DORNALA NAVEEN REDDY) — Fri, 05 Sep 2014 08:14:00 +0000

1. Create folder : C:\Temp

2. Save a text file with the name servers.txt and add server names

3. Create a .PS1 file with the name “ Get-LocalGroupMembers.ps1 ”with below PowerShell code:

**********************************************************

[CmdletBinding()]

Param(

[Parameter( ValueFromPipeline=$true,

ValueFromPipelineByPropertyName=$true

)]

[string[]]

$ComputerName = $env:ComputerName,

[Parameter()]

[string]

$LocalGroupName = "Administrators",

[Parameter()]

[string]

$OutputDir = "c:\temp"

)

Begin {

$OutputFile = Join-Path $OutputDir "LocalGroupMembers.csv"

Write-Verbose "Script will write the output to $OutputFile folder"

Add-Content -Path $OutPutFile -Value "ComputerName, LocalGroupName, Status, MemberType, MemberDomain, MemberName"

}

Process {

ForEach($Computer in $ComputerName) {

Write-host "Working on $Computer"

If(!(Test-Connection -ComputerName $Computer -Count 1 -Quiet)) {

Write-Verbose "$Computer is offline. Proceeding with next computer"

Add-Content -Path $OutputFile -Value "$Computer,$LocalGroupName,Offline"

Continue

} else {

Write-Verbose "Working on $computer"

try {

$group = [ADSI]"WinNT://$Computer/$LocalGroupName"

$members = @($group.Invoke("Members"))

Write-Verbose "Successfully queries the members of $computer"

if(!$members) {

Add-Content -Path $OutputFile -Value "$Computer,$LocalGroupName,NoMembersFound"

Write-Verbose "No members found in the group"

continue

}

catch {

Write-Verbose "Failed to query the members of $computer"

Add-Content -Path $OutputFile -Value "$Computer,,FailedToQuery"

Continue

}

foreach($member in $members) {

try {

$MemberName = $member.GetType().Invokemember("Name","GetProperty",$null,$member,$null)

$MemberType = $member.GetType().Invokemember("Class","GetProperty",$null,$member,$null)

$MemberPath = $member.GetType().Invokemember("ADSPath","GetProperty",$null,$member,$null)

$MemberDomain = $null

if($MemberPath -match "^Winnt\:\/\/(?\S+)\/(?\S+)\/") {

if($MemberType -eq "User") {

$MemberType = "LocalUser"

} elseif($MemberType -eq "Group"){

$MemberType = "LocalGroup"

}

$MemberDomain = $matches["CompName"]

} elseif($MemberPath -match "^WinNT\:\/\/(?\S+)/") {

if($MemberType -eq "User") {

$MemberType = "DomainUser"

} elseif($MemberType -eq "Group"){

$MemberType = "DomainGroup"

}

$MemberDomain = $matches["domainname"]

} else {

$MemberType = "Unknown"

$MemberDomain = "Unknown"

}

Add-Content -Path $OutPutFile -Value "$Computer, $LocalGroupName, SUCCESS, $MemberType, $MemberDomain, $MemberName"

} catch {

Write-Verbose "failed to query details of a member. Details $_"

Add-Content -Path $OutputFile -Value "$Computer,,FailedQueryMember"

}

End {}

***********************************************************

4. Open PowerShell and point to Get-LocalGroupMembers.ps1 and use below commands to get the results.

.\Get-LocalGroupMembers.PS1 -ComputerName (Get-Content C:\temp\servers.txt)

Results will be saved as CSV file and at C:\Temp with the name “LocalGroupMembers.csv”

Source: https://4sysops.com/archives/create-a-list-of-local-administrators-with-powershell/

IIS Virtual SMTP

noreply@blogger.com (DORNALA NAVEEN REDDY) — Thu, 04 Sep 2014 09:48:00 +0000

SMTP Folders

When you install the SMTP service it creates the following default folder structure in order to process mail:

As you can see from the screenshot above, the folder C:\inetpub\mailroot\contains 4 folders; Badmail, Drop, Pickup & Queue. They are explained below in the order that messages are processed:

Pickup

The SMTP service will process messages in the Pickup folder as outbound messages and will attempt to deliver them. To demonstrate what happens when a message is placed in the Pickup folder, perform the following:

1. Create a text file on your desktop called email.txt and paste the following into it, remembering to change the email address information to reflect your own details:

From: blog@yourdomain.com

To: email@yourdomain.com

Subject: Email test

This is the test body of the email

.

2. Save the changes to email.txt and then copy the file toC:\inetpub\mailroot\Pickup. The SMTP server monitors this folder and when it detects the email.txt file, it will read the contents and send the email to the address in the To: section. This should happen almost immediately.

3. Check the email address the email was sent to and it should arrive shortly – the email was sent to my Gmail account:

A quicker way and easier was of emulating the creation of messages in the Pickup folder is to run a PowerShell command that generates an email. Enter the command below, changing where appropriate the -To and -Fromaddresses:

PS C:\Users\admin> Send-MailMessage -SMTPServer localhost -Toxxxxx@gmail.com -From xxxxx@yourdomain.com -Subject "This is a test email" -Body "Hi, this is a test email sent via PowerShell"

Messages generally don’t build up in the Pickup folder, once detected the SMTP server will try to deliver them. If the intended recipient is a member of the local domain, the SMTP service will move the message to the Drop folder.

Drop

Incoming messages intended for the local domain are placed in the Drop folder. It is very unlikely that you will require the use of the Drop folder in a real-world scenario. Messages in the Drop folder must be retrieved using an email client such as Outlook but also require POP3 server software to be installed in order to enable end-users to connect to and retrieve those messages in the Drop folder. Server 2003 had the option to install the POP3 service but this has since been deprecated on versions of Windows Server since then.

If you are seeing that messages that your applications generate are building up in the Drop folder then this will be most likely be caused by configuring the default local domain to use your DNS domain namespace. The best way to illustrate this is to show you an example.

1. Currently my default local domain is configured with the name of my server, WEB1:

2. I use the PowerShell command below to send an email toblog@vsysad.com:

PS C:\Users\admin> Send-MailMessage -SMTPServer localhost -Toblog@vsysad.com -From admin@vsysad.com -Subject "This is a test email" -Body "Hi, this is a test email sent via PowerShell"

The message is subsequently placed in the Pickup folder and processed and routed through to the mail server that handles mail for the vsysad.com domain. This message is delivered successfully.

3. However, lets change the default local domain to be vsysad.com per the below:

The vsysad.com DNS domain is now considered to be a local domain. If I were to use the same PowerShell command from step 2 above, the message will be processed per the usual method but will be placed the Drop folder:

The message will remain there until I use an email client to connect to the server via POP3 to download it. This will require 3rd party POP3 mail server software to enable this.

Queue

Messages that cannot be delivered immediately are moved from the Pickup folder to the Queue folder. The SMTP service will attempt repeatedly to deliver messages in the Queue folder. The number of times it will attempt to deliver the message is configured in the delivery tab, see below:

I have noticed that when delivering emails to domains such as Gmail and Yahoo for the first time, messages will remain in the Queue folder for some time while the SMTP server tries to re-deliver them.

Badmail

Emails that could not be delivered to the intended recipient are left in the Badmail folder. After the number of attempts configured in the Delivery tab (see screenshot above) to deliver the message have not been successful, the message will be moved to the Badmail folder. Messages in the Badmail folder will remain there until administrators diagnose the cause and implement a fix.

Common causes of messages ending up in the Badmail folder are incorrect or invalid email addresses and DNS issues. Follow instructions in these posts toverify DNS and successful mail routing respectively.

Once messages are in the Badmail folder, they can be opened up in notepad and examined. Open up the corresponding .BAD file(s) which will reveal the reason for the message delivery failure. An example is below, whereby the message failed because the recipient’s email address was invalid:

SMTP Domains

It is very important to clarify the distinction between a local domain and a remote domain within the SMTP settings. Choosing the wrong SMTP domain type will result in unintended results.

Local Domains

As stated in the Drop folder section above, a local domain is a DNS domain that is serviced by the local SMTP server. In my example, vsysad.com was the local default domain.

Messages that are received by an SMTP server that are destined for email addresses within the local domain will not be looked up in DNS, they will be dumped straight to the Drop folder. In the case of most environments the SMTP server is used simply to send mail and not to handle incoming mail for that domain. If this is the case for you, do NOT enable yout DNS domain as a local domain within the SMTP server.

You can specify local domains as either default or alias. There can only be one default domain. An alias domain is an alias of the default domain. If you add a new domain and configure it as the new default, the previous default changes to an alias domain.

Remote Domains

Domains that are not designated as local are remote domains. The SMTP service looks up remote domains in DNS and will process the mail according to the settings configured for that specific remote domain. For example, you can add a remote domain and require that the SMTP service always use Transport Layer Security (TLS) encryption in sessions with that domain, which is the case for Gmail.

I hope this post demystifies the various SMTP folders and explains how mis-configuring the domain type can lead to unwanted messages in the Drop folder.

Original Link:http://www.vsysad.com/2014/01/iis-smtp-folders-and-domains-explained/

Difference between Wins and DNS

noreply@blogger.com (DORNALA NAVEEN REDDY) — Fri, 25 Jul 2014 06:20:00 +0000

1. WINS is platform dependent, whereas DNS is platform independent.

2. WINS supports dynamic IP addresses, whereas DNS supports static IP addresses.

3. WINS translates the NetBIOS names to IP addresses, while DNS translates host names to IP addresses.

4. WINS supports incremental reproduction of the data for any modifications, while DNS copies the entire database.

5. WINS does not support TCP/IP application services, whereas, DNS supports all TCP/IP application services.

Source: Difference Between WINS and DNS | Difference Between | WINS vs DNS http://www.differencebetween.net/technology/internet/difference-between-wins-and-dns/#ixzz38SUVnnEi

How To Simplify Your Data Center With Network Automation and Orchestration

noreply@blogger.com (DORNALA NAVEEN REDDY) — Thu, 24 Jul 2014 08:06:00 +0000