Automate your emails processes in less than 5 minutes with
Automatic Email Manager
Receive emails & attachments automatically on your printer, on disk, or converted in PDF
Read more on their web site!
Read more on their web site!
I had a client recently who has all 2008 DCs and wanted to introduce 2016 DCs. No big deal. Prep the domain and forest and off you go. Except that this client was running in 2003 forest mode. And that led to a different discovery: FRS was being used for SYSVOL/NETLOGON replication. And this is not going
to cut it in a modern AD. Migrating is not especially difficult but it requires a little know how, patience and perserverance.
This article by Patrick van den Born was a wonderful resource that had almost all that I needed to get the pieces in place.
*** Make sure to install DFS on all the 2008 DCs but do not create a namespace.
Test replication by going to the “scripts” folder in SYSVOL, adding a text file, and making sure that it IMMEDIATELY appears in all the other DCs’ Scripts folder.
Exchange 2010 was the last iteration that included a decent message tracking log interface. Microsoft intentionally broke that wonder search app with 2013 in order to push admins to use powershell. So, when I had to track down the internal source of an email that was being sent by a job that did not appear to exist (we have dozens of applications that route mail through Exchange) I had to use PowerShell to track down the source IP.
This proved not to be the easiest thing to do. I was not sure where the original source IP even resided. So, I decided to start with everything for the first query and work my way back from there. I also decided to use the wonderful | Out-Gridview feature to pipe the output to a GUI so that I could filter from there.
Here is the query to use:
Get-MessageTrackingLog -Server mail01 -Start “Aug 7 2017” -sender “firstname.lastname@example.org” -resultsize unlimited | select-object TransportTrafficType,SchemaVersion,RunspaceId,Timestamp,ClientIp,ClientHostname,
TenantId,OriginalClientIp,MessageInfo,MessageLatency,MessageLatencyType | Out-Gridview
This gave me the information that I needed. Too much information in fact, which was easily remedied by the Out-View Grid’s “Add Criteria” feature. In the end, it was the OriginalClientIP field that gave me what I needed!
I recently had a client for whom I had to build a new Windows 2016 server. He had not gotten the software yet but I wanted to proceed anyway so I downloaded an eval copy and installed from that. Later, I received the production key for the OS. But simply adding the key is not enough to activate an eval copy; it must be converted to ServerStandard via the command line.
Fortunately, this is easy to do. Just open an Administrative Command Prompt and type:
DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
This will convert the product and install the key at the same time! Please note that the install will appear to “hang” at 10% for a while and will then proceed pretty quickly. Just be patient! Then, reboot once and you are good to go.
The Client required Remote Desktop Sessions to be available to 17 contractors via a hosted server. They also wanted that server to be hosted within their existing Azure/365 portal.
The first thing was to connect their AD to the cloud. AD Connect had already been installed and had done the initial seeding of the accounts for Office 365. But it had not been enabled for password replication and so SSO was not in place. Further, the issue with users not synching properly was only because the user accounts were in the default USERS OU. AD Connect doesn’t like this. Accounts need to be elsewhere.
In order to join virtual servers and PCs in the cloud to the client.com domain and use domain creds for logins to these machines, we had to extend the AD to the cloud. There are a number of ways to do this and the easiest and simplest is to use Azure Active Directory Domain Services (AAD DS). This extends the domain to the cloud with no site to site VPN (which can be done within Azure) and no virtual server running in the cloud as a domain controller.
In the AAD Dashboard, go to Groups and note the AAD DC Administrators
This is a global security group that only exists in the AAD DS world. It contains AD accounts that are allowed to be the equivalent of the Domain Admin role in Azure. You must be in the group to be able to do certain high level functions like joining Azure VMs to the Client.com domain.
Azure VMs are mainly managed in the classic portal and not the new one.
Here are the server information readings as configured by Microsoft on the server desktop
The server’s RDS configuration is set via Add Roles… as seen below
Configurable information for the Session Based RDS Deployment is listed here:
Recently I had a client whom I had migrated AD services from 2008 R2 to 2012 R2. That part of the project went well and when completed, I needed to upgrade their DFS infrastructure to 2008 Mode.
There were issues though and I had to do a few things that I didn’t really like to do. Let’s just say that when you have to use ADSIEDIT.MSC, it’s always a cause for concern!
Here are a few of the references that I used:
https://technet.microsoft.com/en-us/library/cc753875.aspx – procedure for upgraded DFS Namespaces to 2008 from 2000
https://social.technet.microsoft.com/Forums/office/en-US/d77b1057-7854-45a8-9449-20f64bcc2f48/tried-migrating-dfsr-namespace-from-2000-to-2008?forum=winserverfiles – Use ADSIEDIT.MSC to clean up DFS in AD.
https://blog.workinghardinit.work/2011/05/24/move-that-dfs-namespace-to-windows-2008-mode/ – Good article on the process
These are the steps that I took to upgrade the DFS with errors and the remediations that I found needed to be used.
1: Open an admin CMD prompt:
2: Write down the path for each namespace server:
3: In DFS Management, right-click the namespace and then click Delete
4: In DFS Management, recreate the namespace with the same name, but use the Windows Server 2008 mode
5: Import the namespace from the export file
Now, all appears to be well.
I have a client who recently wanted to get a Windows 10 Pro PC for >their office. He went to Best Buy but all they had was Home edition. This is not an issue since you can upgrade Home to Pro with a simple license key upgrade. But it turned out that when I went to install the new key, I got an error. Nice! Follow MS’s procedure and get an error…..
BUT, I was able to track down this solution. Install a temp license key that will allow the actual upgrade to work, THEN install the newly purchased key.
VK7JG-NPHTM-C97JM-9MPGT-3V66T – Install this key first, Reboot, then install the key that you purchased.
support.microsoft.com/en-us/help/12384/windows-10-upgrading-home-to-pro – This is where you go, but you have to install the temp key first, then the correct one.