• Mike Rodrick

    Hey @Adam-Tyler ,

    A root CA is almost always configured as an offline, stand-alone CA for security reasons. If the root CA is compromised, the entire CA infrastructure is compromised. All issued certificates have to be revoked, and the CA infrastructure rebuilt from the top.

    So your understanding is correct, the offline stand-alone root CA cannot be used for auto-enrollment. But this is ok, as the root CA is only used to issue certificates to the first level of subordinate CAs. After the subCA certificates are issued, the root is taken offline.

    So for your questions,

    1. Because the root CA will be offline, it should not be configured on a domain member. By default, computers change their password every 30 days, and if the root is kept offline for longer than this, trust issues will occur. Because the root CA doesn't issue certificates to users or computers, there is no need to store any information in Active Directory, so it should be configured as stand-alone, not enterprise.

    2. Because the root CA is offline, and stand-alone, they usually fall outside of update policies. They can be brought online occasionally to apply updates if you have to, but they are powered off, so little chance for compromise. Depending on your CRL lifetime, the root CA might only be brought online once a year. So when you do bring it online, plan accordingly, there will be a few updates ;)

    3. Yes! This is the best practice for a CA hierarchy. The offline, stand-alone root CA is configured first. Then, enterprise subordinate CAs are configured, and request subCA certificate from the root. Once they are configured, the root is taken offline. The subordinates are enterprise CAs, so they store their information in Active Directory, and support auto-enrollment for users and computers.

    4. Not that I'm aware of. I have used a single-tier hierarchy in test labs, where my root CA was also my issuing CA, but never in production. The root CA is always stand-alone and offline. The root CA isn't used to issue certificates, other than to subordinate CAs.

    Hope this clears things up! Coincidentally, I am shooting shows on this very topic this week. If you get a chance, join us in the chat room in the afternoons!

    posted in Microsoft read more
  • Mike Rodrick

    @Waqkas-Ahmed ,

    What are you trying to do with the If ($existing -eq $null) statement? In this script, I believe it will always be null, since the variable $existing is never set to anything.

    Also, the account is created, or fails, when you run the New-LocalUser cmdlet
    $Account = New-LocalUser -Name $TrimmedUserName
    before the if statement is run. We would need to move this command inside the if statement.

    We can use the Get-LocalUser cmdlet to test if a username exists. Then we can use that boolean to control our if statement. Something like this

    $NewLocalUserName = Read-Host -Prompt "Enter a name for the new user"
    $TrimmedUserName = $NewLocalUsername.TrimEnd()
    $group1 = "Power Users"
    $group2 = "Remote Desktop Users"
    # $Password
    $exists = Get-LocalUser -Name $TrimmedUserName -ErrorAction SilentlyContinue
    
    if (!$exists) {
        $Account = New-LocalUser -Name $TrimmedUserName
        Write-Host "Creating new local user $Account. `n"
        Write-Host "Adding $Account to the $group1 group."
        net localgroup "Power Users" "$Account" /add
        Write-Host "Adding $Account to the $group2 group."
        net localgroup "Remote Desktop Users" "$Account" /add
        Write-Host "Ensuring password for $Account never expires."
        WMIC USERACCOUNT WHERE "Name='$Account'" SET PasswordExpires=FALSE
    }
    else {
        Write-Host "Username already exists"
       # Write-Host "Setting password for existing local user $Username."
       # $existing.SetPassword($Password)
    }
    
    

    posted in Microsoft read more
  • Mike Rodrick

    Hey @Waqkas-Ahmed ,

    One solution would be to prompt them for the name first. Then you can trim the name before you pass it to the New-LocalUser cmdlet.

    $NewLocalUserName = Read-Host -Prompt "Enter a name for the new user"
    $TrimmedUserName = $NewLocalUsername.TrimEnd()
    
    
    $Account = New-LocalUser -Name $TrimmedUserName
    
    $Password
    
    if ($existing -eq $null) {
    Write-Host "Creating new local user $Account."
    
    Write-Host "Adding local user $Username to $group."
    & net localgroup "Power Users" "$Account" /add
    & net localgroup "Remote Desktop Users" "$Account" /add
    }
    else {
    Write-Host "Setting password for existing local user $Username."
    $existing.SetPassword($Password)
    }
    Write-Host "Ensuring password for $Account never expires."
    & WMIC USERACCOUNT WHERE "Name='$Account'" SET PasswordExpires=FALSE
    

    I'm not sure what you are trying to do with the password. Since you are not providing a password when running New-LocalUser, it is prompting them to enter a password. It is stored as a secure string, which doesn't have a trim method. You want them to change it again?

    Let me know and we can fix that too. Hope this helps.

    posted in Microsoft read more
  • Mike Rodrick

    @Waqkas-Ahmed

    I'm not the Exchange guy, but I will try to find some time to set up a test lab and see what I can do. In the meantime, take a look at these cmdlets to get you started:

    For an on-premise Exchange Server
    Get-MessageTrackingLog -Recipients mike@itpro.tv

    For Exchange Online
    Get-MessageTrace -RecipientAddress mike@itpro.tv

    posted in Microsoft read more
  • Mike Rodrick

    Hello @Waqkas-Ahmed ,

    Are you using Exchange? What version are you running?

    posted in Microsoft read more
  • Mike Rodrick

    Hey @Waqkas-Ahmed ,

    This sounds like a really good time to use inbox rules. They are easy to create and would be applied when the email arrives.

    I'm sure it can be done with PowerShell, but I think it would involve much more work. Not only writing the script, but trying to get it to trigger each time a new email arrives. The inbox rules are for this very scenario.

    If there is a reason for using PowerShell instead of inbox rules, let me know, and post what you have so far and I can try to help!

    posted in Microsoft read more
  • Mike Rodrick

    Hey @Daniel-Fiore ,

    Awesome, glad you got it working!!

    I just checked, and the plan is to replace the entire series at once, so the new episodes wont be available until the new show is complete.

    P.S. Just thought I would mention, you can do nested virtualization. Some of the Hyper-V servers I use in the shows are actually virtual machines running on VMWare Workstation ;)

    Glad I could help,

    posted in Microsoft read more
  • Mike Rodrick

    Hello @Daniel-Fiore ,

    We are updating our Microsoft Windows Server 2016 MCSA track starting next week. We plan to start filming 70-740 and 70-742 on Monday. The previous shows were recorded in the last quarter of 2017, and many things have changed since then!

    As for the current content, is is accurate. Lets see if we can get it working for you.

    1. You should be able to install the NuGet package provider. This command hasn't changed. There is a newer version of NuGet available (2.8.5.208). The computer will need an internet connection for the command to work. Also make sure you are running PowerShell with administrative rights. (There is a way to download the package on another machine if you needed to do an offline install) Try leaving the MinimumVersion parameter out and see if that works. Something like this...
    Install-PackageProvider -Name NuGet 
    

    You can verify the package provider was successfully installed by running

    Get-PackageProvider
    

    Here is a link to check out as well...
    https://docs.microsoft.com/en-us/powershell/module/packagemanagement/install-packageprovider?view=powershell-5.1

    1. New-VHD and New-VirtualDisk are different cmdlets that do two very different things. New-VHD is the cmdlet for creating VHDs to use with virtual machines in Hyper-V. New-VirtualDisk is the cmdlet for creating new virtual disks in Storage Pools.

    The PowerShell command New-VHD is part of the hyper-v module. You will need to make sure this module is installed. You can install the module using the Add Roles and Features Wizard, or by using the Install-WindowsFeature cmdlet.

    In the Add Roles and Features wizard, click next till you get to Select Features. In the list of features, navigate to Remote Server Administration Tools -> Role Administration Tools -> Hyper-V Management Tools and select Hyper-V Module for Windows PowerShell.

    To install the Hyper-V module using PowerShell, use the following...

    Install-WindowsFeature -Name Hyper-V-PowerShell
    

    You should now be able to use the New-VHD cmdlet. You can verify the module is installed by running...

    Get-Module
    

    I've verified all of the above commands on Windows Server 2016 version 1607, running PowerShell 5.1.

    I hope this helps, if you have any more questions or issues, just let me know.

    Thanks for watching and being a member!!

    posted in Microsoft read more
  • Mike Rodrick

    Hello @Wilfried-THIAM ,

    Not sure if this is what you are looking for...

    Get-ADPrincipalGroupMembership <username> | Get-ADGroup -Properties * | select name, description
    

    This will return a list of groups a user belongs to and the description for the group, if there is one.

    If you are looking for something else, let me know.

    Mike

    posted in Microsoft read more
  • Mike Rodrick

    Hello @Nagayya-Pujari ,

    Did you go through the post-installation tasks after installing WSUS?

    When adding WSUS to a SCCM install to create a SUP, you should not launch the post-install configuration for WSUS. You will use SCCM to manage WSUS.

    In the site system role wizard, when adding the SUP role, you will specify that WSUS is configured to use 8530 and 8531.

    Hope this helps,

    posted in Microsoft read more