Hola a todos!
Les dejo en esta oportunidad, el acceso al nuevo numero de la revista LatamTechnology #10.
Excelente numero con novedades, artículos de interés, entrevistas y mucho mas!!!
URL: http://www.latamtechnology.com/
Saludos!
LeoPonti
Hola a todos!
Les dejo en esta oportunidad, el acceso al nuevo numero de la revista LatamTechnology #10.
Excelente numero con novedades, artículos de interés, entrevistas y mucho mas!!!
URL: http://www.latamtechnology.com/
Saludos!
LeoPonti
Hola a todos!
En esta oportunidad. quiero dejarles la lista de artículos publicados en el Scripting Guy! Blog durante esta semana. Realmente es excelente el trabajo de Ed Wilson!.
Espero disfruten de los artículos!!
Excelente semana!!
Saludos
LeoPonti
Summary: Microsoft Scripting Guy, Ed Wilson, talks about installing the free Remote Server Administration Tools for Windows PowerShell 3.0 in Windows 8.
Microsoft Scripting Guy, Ed Wilson, is here. This morning is an awesome morning. Our friends from Hamburg, Germany have been hanging out all weekend, and it has been a blast. We have spent a bit of time talking about Windows PowerShell training and some of the challenges related to that. We have also shared a love for tea. Yep. It has been a great weekend. Not only that, but the weather also cooperated—it has been sunny and not too humid.
One of the first things I do when I build a new computer running Windows 8, is install the Windows 8 Remote Server Administration Tools (RSAT) tools. After I do this, I gain access to many new and useful cmdlets that make it easy to administer everything from Active Directory Domain Services to Windows Software Update Services.
For a free download of the tools, see Remote Server Administration Tools for Windows 8 on the Microsoft Download Center. There are two versions available on the download page: a 32-bit version and a 64-bit version. Finding the actual download is pretty easy—I click the big red Download button that is shown in the following image.
I can install the RSAT tools for Windows 8 on computers running Windows 8 or Windows 8 Pro. I cannot install them on my Windows Surface RT, but I can install them on my Windows Surface Pro.
The first thing I need to know is if my computer x86 or is it x64. The way that I usually find this out is to query an environmental variable as shown here:
PS C:\Users\ed.IAMMRED> $env:PROCESSOR_ARCHITECTURE
x86
Before I install the RSAT tools on my computer, I use the following script to to see how many cmdlets and functions are currently on my computer— I have 989.
PS C:\Users\ed.IAMMRED> gcm -CommandType cmdlet, function | measure
Count : 989
Average :
Sum :
Maximum :
Minimum :
Property :
So I click the big red Download button to select my appropriate package.
Now, I have a choice. I can download the package and install it offline. Or if I choose Run, the file spools to a Temp folder, and it performs the installation from there. This works great if I have good Internet bandwidth, and if I do not anticipate needing to perform the installation again anytime soon. I will open the file, and after a quick security scan, the installation begins. Here is the dialog box I see:
While the RSAT installs, a progress bar tracks the percentage of completion. This is shown here:
The first thing I do after the installation is complete is use the Update-Help cmdlet to update the Help for the newly installed modules. This is shown here:
PS C:\Users\ed.IAMMRED> update-help -Module * -Force
After I install the RSAT tools, I check to see how many cmdlets and functions I now have. The number is 1757 as seen here:
PS C:\Users\ed.IAMMRED> gcm -CommandType cmdlet, function | measure
Count : 1757
Average :
Sum :
Maximum :
Minimum :
Property :
Unlike previous versions of the RSAT tools, now when I install the tools, all of the modules and support tools automatically install. In previous versions, I had to go into Programs in Control Panel, select Turn Windows features on or off, and then scroll down to Remote Server Administration Tools to turn on each tool. Now, I only need to do this if I want to turn off a feature. This menu is shown here:
After the tools install and I have updated the Help, I can open the Windows PowerShell console (or the Windows PowerShell ISE) and begin to use the tools. The cool thing is that I can use the cmdlets from the Active Directory module to query a domain controller that is running Windows Server 2008. This is shown here:
PS C:\Users\ed.IAMMRED> Get-ADUser -Filter * -Server dc1 | select -Last 1
DistinguishedName : CN=anothertestuser,OU=Testou,DC=iammred,DC=net
Enabled : False
GivenName :
Name : anothertestuser
ObjectClass : user
ObjectGUID : 36b19f4d-081b-4435-89cf-5979defe8c32
SamAccountName : $9E1000-86BJ2L7MPKB4
SID : S-1-5-21-1457956834-3844189528-3541350385-1481
Surname :
UserPrincipalName :
But I can also use cmdlets that only exist in Windows Server 2012 as shown here:
PS C:\Users\ed.IAMMRED> Get-DhcpServerInDC
IPAddress DnsName
--------- -------
192.168.0.152 wds1.iammred.net
Well, that is about it for today. Join me tomorrow as we begin a series written by Windows PowerShell MVP, Sean Kearney, about automating DiskPart. It is cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Microsoft Scripting Guy, Ed Wilson, talks about the decision points for deciding how to use Windows PowerShell to access Active Directory Domain Services.
Hey, Scripting Guy! I am a bit confused. I see various blogs and scripts on the Script Repository, and some always use a third-party snap-in to access Active Directory Directory Domain Services (AD DS). Others seem to use .NET Framework code to access AD DS, and still others are using a module that looks like it is part of Windows PowerShell. What is the best way to access AD DS?
—CB
Hello CB,
Microsoft Scripting Guy, Ed Wilson, is here. This morning it is actually cool here in Charlotte, North Carolina. In fact, it is way cool because the Scripting Wife found a place on the Internet so she could order some chocolate covered Macadamia nuts. By the way, they go very well with Earl Grey tea with a cinnamon stick. The chocolate, the cinnamon, and the touch of bergamot combine to create an exquisite taste sensation. So, I am out on the lanai sipping tea, nibbling on chocolate covered Macadamia nuts and checking my email on my Surface RT, and I ran across this email to scripter@microsoft.com from CB.
When comparing options for working with Active Directory Domain Services from within Windows PowerShell, one option stands above all the others: supportability. When I use the Active Directory module from Microsoft, it is supported. For me, this means a lot. So if something does not work out perfectly, I know it is supported.
I gain access to the Active Directory module in two ways. On a domain controller that is running at least Windows Server 2008 R2, I add the Active Directory management feature, and I have access to the Active Directory module. I can access it locally on the server, or I can use remoting or implicit remoting to access the cmdlets from my workstation. For more information about remoting, see Use PowerShell Active Directory Cmdlets Without Installing Any Software.
I can also install the Remote Server Admin Tools (RSAT) on my workstation. The version I install depends on the version of the operating system that I have on my workstation. For more information, see What's Up with Active Directory Domain Services Cmdlets?
Note If I install Active Directory Management Service for Windows Server 2008, I do not get access to the Active Directory module on the server. I must install the RSAT tools on my workstation for management purposes. For more information, see Install Active Directory Management Service for Easy PowerShell Access.
In my mind, the cmdlets from the Active Directory module are easy to use. They are a little quirky, but after I get used to the quirks, they simply make sense. Therefore, to create a new user in an organizational unit (OU) named testou in the Iammred.net domain, I type the following:
New-ADUser -Name mynewtestuser -Path 'ou=testou,dc=iammred,dc=net'
If I want to use the [adsi] type accelerator to create a new user, I type something like this:
$adsi = [adsi]"LDAP://dc=iammred,dc=net"
$de = $adsi.Create('user','cn=anothertestuser,ou=testou')
$de.setinfo()
One big problem with using this methodology (besides the fact that it is more typing and less intuitive), is the fact that tab expansion does not work properly. Therefore, some of the methods I want to use do not show up when I press the Tab key.
The advantage, of using the [adsi] type accelerator is that I can use it no matter what version of Windows AD DS is running in. I do not have to have the AD Management service installed, nor do I need a server running at least Windows Server 2008 R2. If my domain meets the minimum guidelines for using the Active Directory module, there is really no decision—I can use the module and use the cmdlets. They are easy, and they are powerful.
CB, that is all there is to using the Active Directory module. Join me tomorrow when I will talk about Windows PowerShell 3.0 in Windows 8. It is a way cool post, and a great way to continue your weekend. See you then.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy