Post on 18-Mar-2023
Metropolia University of Applied Sciences
Master of Engineering
Information Technology
Master’s Thesis
2 June 2021
Jani Ekholm
IT-infrastructure Migration and Modernization
PREFACE Back in 2018 I never thought this would take me so much time to complete. I had the thesis subject in my mind, and I was full of energy and motivation to complete the Mas-ter’s degree. Little did I know. I never had problems with working and studying at the same time. I always had a capacity of doing that and somehow always found the time and strength of doing that. However, things turn to be much more complicated when you add switching a job couple of times during the university. So, during the three years it has taken me to arrive to this point, I changed the em-ployer twice. I had to learn from being an employee at service provider to be the head of infrastructure. I had to change my master’s thesis subject twice and be a bit creative to get all the needed courses done. On top of that Covid-19 was knocking on the door almost all this time making it just a tad more challenging. As if it was not enough al-ready, all this time I had the myocarditis haunting me which seemed to worry me every now and then. Finally, here I am, writing this last bit at 2 am at the night. Feeling a bit empty as it is done now. I am thankful to my boss for letting me have the liberty of doing this project to look like me. Also, big thank you needs to be given for my team and to our service provider project team. Last but probably the most important I am ever grateful to my loved ones. The never-ending support is something I do not take as granted. It is a privilege. Kerava, 2nd of June 2021 Jani Ekholm
Abstract
Author Title Number of Pages Date
Jani Ekholm IT-infrastructure migration and modernization 39 pages + 4 appendices 4 June 2021
Degree Master of Engineering
Degree Programme Information Technology
Instructor(s)
Ville Jääskeläinen, Principal Lecturer Tommi Kaipainen, Chief Digital Officer
This thesis was commissioned by Avarn Security Oy. The purpose was to develop and mod-ernize the information technology infrastructure while merging and migrating users, work-stations and servers from several domains into one main domain. The goal was to achieve a state where IT-environment is stable, standardized and efficiently managed. During the last couple of years Avarn Security had gone through numerous company acqui-sitions. During the business merges IT-functions were not migrated properly and the IT-environment was in a state of becoming seriously complex and extremely hard to manage. The situation was not cost effective either. The project concentrated on migrating the domains together. This included all users and workstation as well as servers. The IT-infrastructure was also modernized apart from very complex network, which was left out of the scope of this thesis. As a result of the thesis the infrastructure was modernized to correspond best practises, processes and standards. Users and workstations were migrated mainly into one domain. Due to nature of the business of the company some users were left to their original domains. Upon the completition of this thesis the infrastructure was advanced to a level where next steps could be taken.
Keywords IT-infrastructure, Migration, Azure, Active Directory, Server
Contents
Preface
Abstract
List of Figures (Tables)
List of Abbreviations
1 INTRODUCTION 1
1.1 Starting Point 2
1.2 Project Plan 3
1.3 Outcome 4
2 CURRENT STATE OF ENVIRONMENT 6
2.1 Architecture 6
2.2 Domains States 7
2.3 SCCM 7
2.3.1 SQL Server / Database 8
2.3.2 SCCM 8
2.4 AD Health Check 9
2.4.1 Active Directory -Domain 9
2.4.2 AD and Network Services 12
2.5 Network 13
2.6 Servers 14
2.7 Users 15
2.8 Workstations 16
3 IMPLEMENTATION PLAN 17
3.1 System Center Configuration Manager / SQL 17
3.2 System Center Configuration Manager 17
3.3 Cloud Management Gateway 18
3.4 Active Directory 18
3.5 Users and Workstations 19
3.5.1 Workstations 20
3.5.2 Users 20
3.6 User Groups and Distribution Groups 21
3.7 Servers 21
4 PROJECT IMPLEMENTATION, PHASE 1 23
4.1 System Center Configuration Manager Upgrade 23
4.1.1 Cloud Management Gateway 24
4.2 Active Directory Upgrade 26
4.3 User and Workstation Migration 27
4.3.1 Users 27
4.3.2 Workstation Migration 28
4.3.3 Migration Finalization 29
4.4 Server Migration 30
4.4.1 File Servers 32
4.4.2 Domain and DHCP Servers 32
4.4.3 Database Servers 33
5 PROJECT IMPLEMENTATION, FINALIZING 35
5.1 Application Server Migrations 35
5.2 Workstation Migrations 36
6 DISCUSSIONS AND CONCLUSIONS 39
References
Appendices
Appendix 1. AD objects
Appendix 2. Forensit parameters
Appendix 3. Master script prevent360 to arok
Appendix 4. Master script ad.avarn to arok
List of Abbreviations
AAD Azure Active Directory
AAG Always-on Availability Group
AD Active Directory
ADK Windows Assessment and Deployment Kit
ADMT Active Directory Migration Tool
ARM Azure Resource Manager
CA Certification Authority
CDP Cloud Distribution Point
CM Configuration Manager
CMAD Configuration Manager Advanced Dashboards
CMG Cloud Management Gateway
CPU Central Processing Unit
CRL Certificate Revocation List
CSP Cloud Service Provider
Cu Cumulative update
DA Direct Access
DC Domain Controller
DFS Distributed File System
DNS Dynamic Name System
DHCP Dynamic Host Configuration Protocol
FQDN Fully Qualified Domain Name
FSMO Flexible Single Master Operations
FTE Full-Time Equivalent
GB Gigabyte
GPO Group Policy Object
HAAD Hybrid Azure Active Directory
HTTPS Hypertext Transfer Protocol Secure
IP Internet Protocol
IT Information Technology
LAN Local Area Network
LAPS Local Administrator Password Solution
LDAP Lightweight Directory Access Protocol
MB Megabyte
MDT Microsoft Deployment Toolkit
MEMCM Microsoft Endpoint Configuration Manager
O365 Office 365
OU Organizational Unit
OS Operating System
PES Password Export Server
PKI Public Key Infrastructure
RBAC Role-based access control
RDP Remote Desktop Protocol
SAN Storage Area Network
SCCM System Center Configuration Manager
SQL Structured Query Language
SSRS SQL Server Reporting Services
SYSVOL System Volume
VLAN Virtual Local Area Network
VPN Virtual Private Network
1
1 INTRODUCTION
This thesis was conducted to Avarn Security Finland Oy. Avarn Security is a company
offering security related solutions. Main businesses are alarm receiving center services,
technical and intelligent technology security services and physical security services. The
company has approximately 4000 employees of which around 700 are office workers.
Company has 15 offices across the country concentrated on areas of center of growth.
Avarn Security has a sister company called Avarn Cash Solutions which is a money
handling company and works independently from Avarn Security on daily operations.
Avarn Security Finland is part of global Avarn Security. The company is lead from Nor-
way and was previously known as Nokas. Due to company merge between Nokas and
Avarn Security, the company has around 18000 employees globally. The name was cho-
sen to be Avarn Security. The company operates in Norway, Sweden, Denmark and
Finland. Each country operates on their own, although there are close relations between
Norway, Sweden and Denmark whereas Finland is more independent in all operations.
Avarn Security Finland’s mission is to be future of the security. Company’s desire is to
be one step ahead and ensure that customer’s investments are reasonable, serves the
purpose and are upgradable in years to come.
The thesis has been divided into 6 sections.
Figure 1. Thesis sections and flow
2
The first section gives background information and introduces the problem. On the sec-
ond section the current state analysis of the environment is done. The third section pre-
sents the actual project plan and actions needed. Fourth and fifth section describes what
was done during the project regarding thesis subject. And finally on sixth section pre-
sents the thoughts of the project and some suggestions to what could have been done
differently and how to proceed to improve the environment from where the project ended.
1.1 Starting Point
This thesis was conducted as a project for Avarn Security Finland. The company was in
a situation where there had been many business acquisitions and bought companies
were merged to Avarn security. This had been happening on quite fast intervals to get
the businesses unified and to have full advantage of the acquisitions. The evolvement of
the company can be seen on Figure 2.
Figure 2. Company evolvement
Over time the support functions, mainly the information technology, had been left on its
own and had been only taken care of minimally. One factor on this was the fact of many
key people changing the employer.
Onboarding IT environments had been done merely by creating trusts between domains
and no real merge or migration had been done. The situation was close to chaotic from
information management point of view and as such, quite a lot of things and processes
3
were not completed in an orderly fashioned manner. This caused the situation to evolve
to a point where there was quite a lot of stocked up things to be changed and redesigned.
Due to many company acquisitions environments needed to be blended. Also, since the
current environment consisted of 7 domains some methods, fundamentals and technol-
ogy were different. A project for migration and modernization and harmonization was
needed.
1.2 Project Plan
The project plan was divided in 4 actual phases:
1. Current state analysis
2. Plan and specifications for new infrastructure based on current state of analysis
3. Implementation phase 1
4. Implementation phase 2.
Figure 3. Project flow
First the environment needed to be analysed and investigated. Due to massive size of
Information Technology (IT) -infrastructure the scope was limited to only needed man-
datory parts of the infrastructure for migrations. The scope included:
• Active Directory (AD) health check
• System Center Configuration Manager (SCCM) and related services
• Workstation inventory
• Server inventory
• Azure services related to workstations and servers
• User account inventory.
The implementation plan was done while results of current state analysis was progress-
ing. The plan included setting up and modernization of the backend. After that the user
4
and workstation migrations testing was conducted, and finally mass migrations of users
and workstations was implemented.
The implementation processes were divided into two parts where the server related mi-
grations and modernizations were done first. Workstation and user migration tests were
done on first phase as well and the actual migrations were done separately on the sec-
ond phase.
1.3 Outcome
After the migrations project there should be left three domains and Azure cloud in use.
The after project -status is illustrated in Figure 4.
Figure 4. Domain environment after migrations
As seen from Figure 4 all the users and devices will be within 3 domains. Arok will be
the main domain having all users. ARC will remain having the personnel belonging to
alarm receiving center business and it will continue with bidirectional trust relationship
with arok domain. Cash domain will also remain as it was earlier being independent and
having bidirectional trust relationship with arok domain.
5
After the migration users will be in one domain in arok, excluding arc and cash. Same is
with the workstations. Azure cloud will be used with multiple features and that is why the
environment can be considered being a hybrid infrastructure.
6
2 CURRENT STATE OF ENVIRONMENT
Current state analysis was done over period of three months. Data was collected mainly
by observing events in infrastructure. Tools used to collect data were mainly native tools
of servers and workstations. Additionally, some Azure provided tools and network tools
were used to collect data and necessary information of the environment. Author’s
knowledge of the infrastructure and architecture was also used heavily during the ana-
lysing of the current state.
2.1 Architecture
On the high-level architecture, the core infrastructure is split in five different datacenters
in 4 different locations. Connectivity between datacenters doesn’t follow any standard
network topology. The topology used could be considered as being a pipe. With such
design it had a high risk of failing services since should the connection break at any point,
it would affect on connections between datacenters. Illustration of the architectural state
at the beginning can be seen from Figure 5.
Figure 5. Architecture at the starting point
During the project the architecture was redesigned to correspond the new environment.
However, high level architecture was left out of the scope of the thesis.
7
2.2 Domains States
Due to many company acquisitions environments had been left to be without any real
effort to unify them. The environment consisted of seven domains at the starting point.
Users, workstations and servers located among all domains. AROK was the new domain
which was aimed to be used as well as Azure cloud.
Figure 6. Domains and relations at the starting point
Domain trusts had been following the company acquisitions so that G4S, ISSSEC and
Turvatiimi domains had common services whereas AD.AVARN and Prevent360 had
common service between themselves as well. Azure and Office 365 (O365) features and
services were enabled from prevent360 domain and were distributed to other domains
via trusts.
2.3 SCCM
SCCM investigation consisted of two main components, the Structured Query Language
(SQL) server and the SCCM server. During the investigations quite a few items were
discovered that were either missing or were not configure properly. Installation and com-
ponents were old yet not outdated.
8
2.3.1 SQL Server / Database
Memory settings were not configured properly. Database memory usage configuration
was partly correct, but some adjustments could be done. Performance options were also
set improperly, and some settings were missing.
Antivirus software was set to scan everything without exclusions on SCCM related SQL
processes and files.
2.3.2 SCCM
SCCM server was analysed and the following shortages were identified:
• Reporting services were missing completely so there was no reporting of the
SCCM available. Additional Configuration Manager Advanced Dashboards
(CMAD) reports were also missing.
• SCCM had default accounts in use such as Administrator. Some services has no
account at all.
• SCCM found to be outdated. Windows Assessment and Deployment Kit (ADK),
Microsoft Deployment Toolkit (MDT), SQL and SCCM all had old versions run-
ning.
• Boundary networks were missing some of the production networks. Networks
added to boundary networks were configured as subnets.
• Client settings were incomplete. Remote tools rights were missing. Hardware in-
ventory was not updating on frequent enough intervals.
• Discovery methods of AD system discovery and AD groups discovery were not
supporting the environment.
• There was no usage on SCCM Role-based Access Control (RBAC) roles.
9
• Company had Azure in use. There was no cloud management gateway or cloud
distribution point configured.
2.4 AD Health Check
Active Directory Health check was done based on Microsoft best practises. Data was
collected by running different diagnostics applications in the environment.
2.4.1 Active Directory -Domain
Forest consisted of one domain arok.fi. Functional level was 2016 on both forest and
domain.
Figure 7. Forest and domain mode
Active Directory schema was on level 87 which means server windows 2016. Exchange
was on 2016 cumulative update (cu)18 level. Cumulative updates are released quarterly,
and they address issues and add new features and functionality. The level is a running
number. [5]
Figure 8. AD schema
AD-site consisted of single site AROK. Domain controllers were located on AROK. Group
Policy Objects (GPOs) were not linked on site. Active Directory had only couple of sub-
nets configured.
10
Figure 9. AD-site
Subnets were missing from configuration since some clients were not able to find a site.
Figure 10. Netlogon log of clients having no site
Replication between domain controllers was automatic. AROK domain had two domain
controllers which replicated between themselves.
Figure 11. Replication summary
System Volume (SYSVOL) -folder on domain controllers held all group policies and net
logon scripts. The replication was separate from AD and used Distributed File System
(DFS) -replication.
Organizational unit structures were found 57. User container had only system account
and AD’s accounts. No abnormal accounts were found. Computer container was also
clean of unnecessary accounts. 9 empty organizational units were found.
11
Flexible Single Master Operations (FSMO) roles were all on AROKDC01.
Figure 12. FSMO
Arok.fi domain had trusts with foreign domains. Trust relationships were found bidirec-
tional with turvatiimi.local, g4s.fi, prevent360.biz, ad.avarn.fi and intra.cash.fi domains.
Figure 13. Domain trusts
AD objects found are listed in appendix 1. Noticeable was that there was quite a lot of
objects not used which indicated of regular maintenance had not been done. Also, when
scrutinized the AD object list it was noticeable number of accounts which had their pass-
word never expiring.
Administrative rights were a little bit based on roles. However, Domain Admins group
had 12 direct members and Administrators had 47 direct members.
12
2.4.2 AD and Network Services
Both domain controllers had Domain Name System (DNS) service installed for internal
name resolution. 5 zones were found, 3 were forward lookup zones and 2 were reverse
lookup zones.
Figure 14. DNS zones
All DNS services were AD integrated. All zones had secured dynamic updates and there
were no zone transfers configured on any zones. All zones had scavenging time of no-
refresh interval two days and refresh interval three days. Time period matched with Dy-
namic Host Configuration Protocol (DHCP) scopes lease time. Old records were deleted
every five days. Both DNS servers had Elisa forwarders. The conditional forwarders are
shown in Figure 13.
Figure 15. Conditional forwarders
Active Directory had two authorized DHCP servers, arokdc01 and arokdc02. Centralized
DHCP was not in use on sites, but only in datacenter and headquarter connections.
DHCP servers were configured as cluster with load balancing. Both servers could assign
Internet Protocol (IP) addresses. Load balancing was configured AROKDC01 75% and
AROKDC02 25%. AROKDC01 was the primary server so all the configuration changes
had to be done on AROKDC01 and then synchronized to AROKDC02.
13
Public key infrastructure (PKI) was present on domain. FIAROKPKIROOT server had
offline root certification authority (CA) which was valid for 20 years. The server was being
restarted once a year to update certificate revocation lists.
FIAROKPKISUB01 was the server issuing Enterprise CA which was valid for 10 years.
Server was domain joined and was issuing certificates for servers and workstations.
CA server certificate revocation lists and own certificates were published on public ad-
dress crl.avarnsecurity.fi which was running in Azure storage service. Certificate revoca-
tion lists (CRLs) are not published in AD.
Generally, the state of the AD environment was good with some things to be improved.
Also noticeable about Active Directory principles of usage was the missing security tier-
ing and therefore somewhat non-standard security layering.
2.5 Network
Network was examined on layer 2 and layer 3 to prevent from mishaps. Network com-
plexity is horrendous and since the thesis was about migration and modernization of
infrastructure any network related areas was left out of scope, apart from the components
crucial to functionality of the virtual platforms, storage systems, Storage Area Networks
(SAN) and other server hardware. Since routing network traffic is mainly done on Layer
2 in Local Area Network (LAN) segments core and fabric switches would need to be
partly reconfigured to advertise correct Virtual Local Area Network (VLANs).
14
Figure 16. Network layout
As seen from the figure 15 the network is quite complex and had to be considered when
planning server migrations and relocating servers within different networks.
2.6 Servers
Servers were located on all domains. ARC and CASH serves were out of scope so there
was total of 5 domains of which the migrations needed to be done from. There were
multiple operating systems and around quarter of the servers had legacy operating sys-
tem.
Figure 17. Server operating systems
15
Azure Service mapping was used as a tool to map server relations. The method helped
to find server relations so that when domain migrations were done, the fixes could be
applied on application level on related servers.
Figure 18. Azure Service Mapping
As seen from Figure 17 Azure service mapping as a tool provided information of relations
with Fully Qualified Domain Name (FQDN), IP and ports used. This information was used
to create the master list of server migrations order.
2.7 Users
Users were located on 7 different domains as displayed in Figure 4. ARC and CASH
domains were not part of the migration project, so they were left out of scope. User ac-
counts belonging to office workers had O365 enabled and had Azure synchronized cre-
dentials.
16
2.8 Workstations
Workstations were located also in same domains as the users and same rules and prin-
ciples would apply. ARC and CASH were not part of the migration project, so they were
not in the scope. Depending in the member domain, workstations had different ways of
creating a remote connection to office network. Direct Access (DA) was used by ad.avarn
domain and Virtual Private Network (VPN) was used on rest of the domains.
Figure 19. Workstation operating systems
The environment consisted of many different versions of operating systems. It looked
like no real image management had been practised.
17
3 IMPLEMENTATION PLAN
Implementation plan was based on the findings of environment analysis. It was carefully
planned and designed to improve the current underlaying infrastructure so that the mi-
gration processes could be done smoothly.
3.1 System Center Configuration Manager / SQL
To improve SQL efficiency the minimum server memory was to be raised to 8 gigabytes
(GB). Since the server had 4 Central Processing Unit (CPU) cores the tempdb database
amount needed to be raised to 4 as well. Each tempdb would have starting size of 512
megabytes (MB) and autogrowth enabled.[1]
To improve performance and reliability antivirus would need to be tweaked so that it
would not check SQL and SCCM processes and files.[3]
3.2 System Center Configuration Manager
SCCM environment didn’t have any alarming flaws, however, some tweaking and fixing
were found. Since reporting services and CMAD reports were missing, they would need
to be installed. [6]
SCCM had default accounts in use which needed to be replaced for security reasons.
Used accounts would need to be created on AD and then have correct privileges for
SCCM usage. This would be achieved by using AD groups and SCCM RBAC roles. [7]
SCCM components ADK, MDT, SQL and SCCM itself were needed to be updated.
Boundary networks would need to be reconfigured and the missing networks from old
domains were needed to be added. Also, the network types needed to be changed from
subnets to IP-ranges. Client settings regarding remote options, inventory and discovery
needed to be reviewed. [8]
18
3.3 Cloud Management Gateway
As an improvement Cloud Management Gateway (CMG) needed to be configured so
that computers would receive patches over internet. There were three points that needed
to be met before deploying CMG.
• Azure Subscription
An Azure subscription is needed to host Cloud Management Gateway (CMG).
CMG doesn't support subscriptions with an Azure Cloud Service Provider (CSP).
• Configuration Manager
Configuration Manager should be updated to newest available version.
• Hybrid Azure AD Joined Devices
All devices should be Hybrid Azure AD joined.
Having the CMG deployed the work needed to be split in parts. Configuration Manager
needed to be updated and after that Azure AD Connect would need to be updated. After
that Hybrid Azure AD join could be setup. Then CMG authentication certificate from pub-
lic certificate authority needed to be acquired and finally Cloud Management Gateway &
Cloud Distribution Point (CDP) could be setup. After the setup would follow number test-
ing and possibly troubleshooting. [9]
3.4 Active Directory
Based on the AD health check there was quite a few improvements and fixes that needed
to be done. Also some cleaning of the unused objects was recommended. The tasks
were divided into two groups, essential and recommended actions.
Essential actions:
• AD-site subnet update
• AD unsecure Lightweight Directory Access Protocol (LDAP) connections review
• DHCP server pool increase
• GPO user and computer objects review
• GPO overlapping objects review
19
Recommended actions:
• AD extra backups
• Organizational Unit (OU) structure review, duplicate rename
• OU structure review, remove unnecessary
• AD objects review, cleaning and removing unused
• GPO objects review and cleaning
• AD password policy hardening [10]
Since the tiering model was missing it was decided to be implemented. At the same time
the administrative rights of AD were reviewed. The tiering model was to follow Microsoft
best practise. In the model there are three groups where the administrative account
would belong to depending on the role.
Figure 20. Administrative tiering model
Tier-0 would be merely for domain admins and their respective accounts. Tier-1 would
hold accounts responsible of server administration and tier-2 would be for end user de-
vice administration. That way would be achieved a layered security so that if one tier
would be compromised no other tiers would be affected. [4]
3.5 Users and Workstations
Regarding user and workstation migrations it was planned to be done in three steps.
First the user would be migrated using Active Directory Migration Tool (ADMT) so the
temporary migration would be done. After that the workstation would be migrated using
20
Forensit migration tool. Third the final scripts would be run to make the actual migration
live. After completion number of checks were to be completed. [18]
3.5.1 Workstations
According to high level plan migration would be done so that first the workstations from
ad.avarn and prevent 360.biz domain would be brought under arok SCCM management
with group policies.
When the computers would be connected to Arok SCCM then the SCCM was to be used
to deploy migration batches to workstations. This would deploy the scripts and tools
needed to every workstation.
Operating systems would need to be upgraded prior to the migrations. As a golden image
the Windows 10 2020 H2 (20H2) version was to be used. Workstations that had Windows
7 as operating systems were left out of scope. Workstations having W7 were to be rein-
stalled with W10 20H2 image or then if the workstations would be end of life leasing wise,
whole new workstations would be installed with the said Windows image.
3.5.2 Users
Tool to be used for the migration was Microsoft ADMT. Tool was already installed on s-
admt.ad.avarn.fi server. ADMT tool would need to be configured to synchronize also
needed exchange attributes so that they would not be needed to be added manually.
Password export server (PES) extension was also to be used in the process of user
migrations to enable password migrations.
Planned migration phases were:
• Mapping of accounts to be migrated
• Configure the tools used for migration, ADMT and Azure Active Directory (AAD)
Connect.
• GPO reviews
21
Due to hybrid environment and Azure AD users would be migrated to arok.fi domain to
temporary OU which would not be synchronized to Azure. Then the account on old do-
main would be moved to OU that would not be synchronized and the account would be
removed from synchronization group. Then the AAD connect would be run to have the
migrated user connected with Azure AD user. [17, pp.78-81, 86-91]
3.6 User Groups and Distribution Groups
User groups and distribution groups would not be migrated from any source domain.
Target domain would have all the needed user groups and distribution groups.
3.7 Servers
Generally migrating a server would be done in three steps. Premigration actions would
be the tasks that would prepare the server for migration. These would be consisted of
monitoring, networking, backup and documentation.
Migration would hold all the actions needed to make the server migrated to new domain.
After migration finalizing actions would take place. This would include reviewing moni-
toring and networking. Also server settings and services would be reviewed.
Servers having old unsupported operating system versions would first be migrated. If
there were any errors the server would be rolled back to old domain and would be left
there to wait for rebuild to new domain with new Operating System (OS).
Active Directory
Active directory servers would not be migrated. Old domain controllers would be shut
down once they would be coming unneeded and no relations to other servers and ser-
vices were existent.
DNS
Security settings and configurations would need to be standardize. Also some cleaning
would need to be done regarding zones. Conditional forwarders would need some tweak-
ing.
22
DHCP
DHCP servers would not be migrated. Only the needed scopes would be created to
arok.fi domain.
Fileserver
There were two possible scenarios how to migrate the file server. It was planned to mi-
grate all on occasion to minimize user interruption. After file migration the namespace on
DFS was to be changed and drive mappings would need to be reviewed.
Application Servers
Application servers would need to be migrated on individual basis. Since the IP ad-
dresses and networks were not changing and the old domain controllers would remain
on, there was no risks of applications not working.
Database Servers
Database servers were left out from migration scope. During the environment analysis it
was noted that there were no standardized database builds and the database versions
were different on many occasions. Instead of migrating the old databases it was decided
to build a new cluster from scratch. The cluster would be Always-On Availability Group
(AAG) cluster with Microsoft SQL server 2019.
23
4 PROJECT IMPLEMENTATION, PHASE 1
The project was divided in two main parts. During first part backend infrastructure was
upgraded and updated to the necessary accepted level. This included SCCM services,
some SQL services and AD-related services. During first phase was also implemented
some new features to improve and ease the migration processes.
Before migrations DNS records and DHCP scopes were set to use name objects and IP
ranges from old domains. DHCP scopes were moved to DHCP servers on AROK do-
main. The scopes then were activated when first client would need their IP pool.
DNS names were updated to new domain when migrating the servers. This would have
caused some errors in name resolving between those clients not migrated and the mi-
grated servers. The problem was prefixed by adding a record to old DNS with the same
IP address as before migrations.
4.1 System Center Configuration Manager Upgrade
Based on the findings SCCM went through quite a few changes.
Reporting services were installed on SCCM SQL server. Usually reports would be in-
stalled on separate SQL Server Reporting Services (SSRS) server but since the infra-
structure had none available, it was decided to install the reports temporarily on SQL
server to have the reporting available. [11]
Service accounts used by SCCM were revised. General administrator accounts were
disabled and every account used was created to be domain accounts. Then the role-
based access was given following least privilege. [12, 13]
Networks from old domains were added to SCCM network boundaries. Missing VPN
network were added and all company used networks were inspected. Those still in use
were added to SCCM boundaries. All networks were configured to be or reconfigured to
be IP address range networks. [8]
24
Figure 21. SCCM boundaries
Client settings were reconfigured so that native SCCM tools could be used to control
workstations. This included remote tools, discovery methods and inventories. [14]
SCCM server antivirus was configured to bypass scanning tasks regarding SCCM and
SQL processes and services. [3] Firewalls were configured to allow traffic between
SCCM and workstations. [15]
Finally a golden image was made of the Windows 10 20H2 version. Upgrade image of
the same version was also made. The version of H2 was chosen since it had the longer
lifecycle and support. [16]
4.1.1 Cloud Management Gateway
To support modern workstation management Cloud Management Gateway was config-
ured to be used. Since the Configuration Manager (CM) was already updated during
SCCM modernization AAD Connect was inspected to match the needed criteria. Since
company was just recently moved to use hybrid O365 environment AAD connect was
configured with hybrid features. Rest of the installation steps were:
• Azure AD Connect update
• Hybrid Azure AD join setup
• CMG authentication certificate from public certificate authority
25
• Cloud Management Gateway & Cloud Distribution Point setup
• Testing & Troubleshooting
Devices would need to be Azure Active Directory (AAD) or Hybrid Azure Active Directory
(HAAD) domain-joined systems. Microsoft would recommend joining devices to Azure
AD. Internet-based devices could be used Azure AD to authenticate with Configuration
Manager. It would also enable both device and user scenarios whether the device was
on the internet or connected to the internal network. [19]
HAAD was tested during the migrations so users belonging to test group were mainly
from IT department. This enabled also quite extensive testing and troubleshooting. Dur-
ing the piloting no real issues were risen so it was decided to go live with the configuration
and make all devices HAAD joined. In order to get all the workstations receive the policy
of HAAD domain join, either VPN connection to on-premises needed to be established
or the user would need to visit office to plug in the workstation to office network.
Authentication of the CMG by the clients was configured as the certificate from a public
and globally trusted certificate provider. I was also possible to use wildcard certificate.
Nevertheless, the certificate was used which had globally unique name to identify the
service in Azure. On network level the secure communication channel between the two
was Hypertext Transfer Protocol Secure (HTTPS). [20]
Finally the Cloud Management Gateway (CMG) and the Cloud Distribution Point were
configured:
• CMG name was chosen and validated, xxxyyyzzz.cloudapp.net was chosen
• Internal and public DNS changes were corresponding the DNS record chosen for
the service.
• Certificate from a public and globally trusted certificate provider was already ex-
isting so it was used.
• Configuration Manager got tweaked by enabling enhanced http for site systems
• Cloud Management
Azure web app & Native Client app were created in Azure.
• Cloud Management Gateway & Cloud Distribution Point
Azure Resource Manager (ARM) was created in Azure. [21]
26
Figure 22. CMG overview
4.2 Active Directory Upgrade
Active directory was generally in a good shape and forest and domain levels were on
needed level. It was discovered that approximately a year ago a project improving AD
was raised but it was never finished. Therefore some of the elements were already pre-
sent in the environment yet they were not finalized. The AD-site was fixed first so that all
members in domain would benefit from AD replications. [22]
Unsecure LDAP connections were monitored using two different methods. On domain
controllers LDAP logging was enabled. After couple of days the events were examined
using script. [23] As an alternative method the native Microsoft tool was used to compare
the results. [24] It was found out that there were no differences in either of the methods
and as the results were obtained it was clear that there was the certificate in use securing
LDAP connections.
Active Directory tiering was done on three levels.
• Tier-0
Domain controllers, high security systems, domains admins, high security ac-
counts
• Tier-1
Other servers, admin workstations, admin accounts, service accounts servers
• Tier-2
Regular accounts, workstation admin accounts, service accounts workstations
27
Active Directory rights delegation was done with same principles. For example, tier-1
credentials had no access rights over tier-0 groups or accounts. GPOs were categorised
to tiers and delegations were granted accordingly. Whole tiering model was noted to be
quite massive change with all the relations to virtual platforms, so it was decided to create
a separate project for the rest of the settings belonging to tiering model.
Last the suggested DHCP pool was increased to hold 254 hosts. Group Policy Objects
were reviewed and unneeded were disabled from use.
4.3 User and Workstation Migration
Users and workstations were migrated on three parts. First the users were migrated us-
ing ADMT tool. During this the user was migrated to arok.fi domain from old domain and
held in temporary OU waiting for other steps.
Second step was to migrate user’s workstation using Forensit migration tools. This ena-
bled user having their workstation profile to follow to new arok.fi.
Third step was to activate the migration steps made so that the users would have their
account synced to Azure AD, have their workstations profiles in new domain and have
their email attributes synced to new domain.
4.3.1 Users
For the first user migration 20 users were added to csv-file. File included two attributes,
the source attribute and the destination attribute. Attributes used were sourcename and
targetSAM. During the migration everyone’s targetSAM attribute was also changed to
forename.lastname format.
Figure 23. ADMT input file format
After the list of names was made and the csv-file was created, it was used with ADMT
tool. From the ADMT tool the related domains were selected.
28
Figure 24. ADMT tool, domain selection
Then the tool was used to select the input from csv-file, target OU selected and made
sure that passwords were migrated as well. Target accounts were enabled, and their SID
was migrated to target domain to remain the relationship with correct AAD object. Ex-
change attributes needed to be also migrated to have the office 365 mailbox synchroni-
zation with correct mailbox.
Figure 25. Exchange attributes
After completing the wizard users were migrated to temporary OU where there was no
synchronization to Azure. Also the user account from old domain was moved to the OU
without synchronization and the synchronization group was removed. After this the step
2 could be made and then finally step 3.
4.3.2 Workstation Migration
Workstations were migrated using the Forensit migration tool. The tool was run by scripts
as a silent tool so no user interaction with the tool was necessary. As preparations some
prework needed to be done. First, the user needed to be migrated first by ADMT tool.
Second if the user account format changed from anything else that forename.lastname
the account attributes needed to be added in response file. The files were located in a
29
network share on each target domain controller. Ad.avarn domain had DA on the work-
station so before migrations it needed to be removed. This was done by simply removing
the workstations from corresponding group and removing every DA-beginning registry
keys from HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNS
Client\DnsPolicyConfig\.
During the migration the workstation needed to be attached to network via network cable.
Migration was done with the credentials having local admin rights on migrated computer.
There was two ways of running the migration, either from network location or by copying
the files locally on the migrated workstation.
In workstation migrations itself there were three steps on this phase when the migration
was done manually. First the workstations had their DA settings removed as described
above. For easing the step, the script was made.
# Remove Direct Access settings $reg = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPoli-cyConfig" Get-ChildItem -Path $reg |ForEach {Remove-Item $_.pspath}
After DA was removed the actual migration was done. This was done by running the
Forensit tool executable profwiz.exe. The profwiz parameters are presented in appendix
2. The scripts for Forensit profwiz are presented in appendices 3 and 4. After the migra-
tion was done then the BitLocker key was backed up to AD by running another script.
# Backup Bitlocker Recovery Key to AD $AllProtectors = (Get-BitlockerVolume -MountPoint $env:SystemDrive).KeyPro-tector $RecoveryProtector = ($AllProtectors | where-object { $_.KeyProtectorType -eq "RecoveryPassword" }) Backup-BitLockerKeyProtector -MountPoint $env:systemdrive -KeyProtectorId $RecoveryProtector.KeyProtectorID
Once this was done the migration was ready for final steps.
4.3.3 Migration Finalization
When the ADMT migration and forensit migration was done, final steps needed to be
done. At first the user was added to synchronization group sg_O365. This was to enable
the O365 and Azure AD synchronization. Also the user account in arok.fi domain was
30
moved from temporary migration OU to actual production OU. The user account in old
domain was then moved to OU holding migrated users. Old user account got also re-
moved any synchronization groups. Finally the user account in arok.fi was reviewed to
have all needed groups like VPN and access control groups. After the checks were com-
pleted AAD connect was manually forced to synchronize with Azure to get the details
updated quicker.
Once everything was done users got informed either by phone or sms that they got now
login to the workstation with new arok.fi domain credentials. At the same time it was
monitored that users could actually log in and that VPN client was installed.
4.4 Server Migration
In general the server migration followed the predefined steps which consisted of three
main parts. Before migration, migration and after migration was done on said order on
each server. Depending on the server role there was some variations and extra steps.
Before Migration
Before the migration some checks and actions were done. First the server was put on
pause on monitoring system. Then the local administrator account was created which
was given a strong password. From the server domain controller availability was checked
by pinging the DC. If the server was virtualized, a snapshot was taken. If there was a
need to change the IP or subnet a new one needed to be acquired. Then the new IP had
to be tested for overlaps and reachability. The source GPO was checked and compared
to the one in AROK domain. Any changes needed to destination GPO were made.
Old IP configuration was then saved documented. Other things documented before mi-
grations were Remote Desktop Protocol (RDP) settings and local users, log on as a
service privileges, dynamic and static routes and persistent routes, time synchronization,
shares and certificates.
Migration
Migration was done manually and no automation was used with servers. This was due
to nature of the servers and each server being different so the automation script would
31
not be helpful since there was no universal migration. The migration process included
the following flow:
• Sign-in to server with local account
• Remove the server from old domain
• Boot
• Update the DNS settings on the server
• 172.30.0.11
• 172.30.0.12
• Update the IP address changes if necessary
• Join the server to arok.fi domain
• Move the server to Arok.fi/AROK/Computers/Servers/Migrated OU
• Remove the server from old DNS zone, unless needed for name resolving for
legacy systems
• Review the PTR records
• Move SCCM client to arok.fi domain
• Configuration Manager Properties -windows, Sites -tab
• Configure Settings, accept UAC
• Currently assigned to site code – insert FIN
• Review RDP and access settings
• Review local user rights
• Review and monitor the services
After Migration
After the initial migration some steps needed to be completed to achieve full functionality
of the server. Old antivirus was uninstalled and new Sophos-client was installed. Backup
policy of the server was reviewed from VEEAM and necessary changes were made.
Then the server was assigned to monitoring again and all AD groups needed were
added.
For distributing updates via SCCM 4 groups were made. Each server was added to the
group best fit.
• sg_sccm_srv_updates_production_group_1
• sg_sccm_srv_updates_production_group_2
• sg_sccm_srv_updates_production_manual
32
• sg_sccm_srv_updates_production_pilot
Time synchronization and time zone was checked and then Local Administrator Pass-
word Solution (LAPS) was installed and enabled. After everything had been confirmed
to be working, earlier created snapshots were removed, and the created local admin
account was removed.
4.4.1 File Servers
A separate disk was made to arokfil01 fileserver for the data to be migrated. After all the
access rights were inspected by using scripts then the data was migrated from source
file server to arokfil01 server. Process for this was that first the target server file shares
were set to read only. Then the datadisk was copied from target server to earlier created
separate disk on arokfil01 server in vmware. Then the shares were created on the mi-
grated disk on arokfil01. After that the DFS namespaces were done to arok.fi domain.
Next the access control rights were reviewed and created in arok.fi domain and the users
were let to access the shares.
Since the old domain and arok.fi domain had overlapping assigned drive letter they were
reviewed. P-drive was set to host the shares that were migrated from old file server. The
decision was logical since the data was migrated from Prevent360 domain and P-drive
was good option to describe it.
4.4.2 Domain and DHCP Servers
Domain servers were not migrated. Since users were migrated with all necessary attrib-
utes and target domain had all user groups and distribution groups needed, no domain
servers needed to be migrated. Old domain servers were eventually shut down when all
related services had been moved to new domain and no connections were established
on old domain controllers.
DHCP scopes on old domains were added to arok.fi domain so that no IP addresses
would need to be changed. IP helper addresses were changed on routers to correspond
to arok.fi DHCP servers. On the arok.fi servers the DHCP lease times were standardized
to 5 days on each scope.
33
Old unnecessary zones were removed. Dynamic updates were set to secure only since
there was no real reason to differ from the setting. After unnecessary zones were re-
moved zone transfers were created as needed. There were quite many scenarios where
old domain details were needed on certain application servers. Therefore each old do-
main was added as conditional forwarder to guarantee application functionality. Due to
complex environment and numerous rare legacy applications references to old domain
name records were needed to remain. [18]
Figure 26. DNS server after migration
4.4.3 Database Servers
SQL servers were not migrated from old domains. New AAG cluster was built to arok.fi
domain which would then act as a main SQL cluster. Cluster was implemented from two
virtual servers with following specifications on one server:
• vCPU: 8 cores
• RAM: 128GB
• Discs: C:-drive 100GB, instance discs were added separately depending on the
instance requirements
• OS: Windows servers 2019
• SQL version: SQL Server 2019 enterprise edition
• SQL licenses: 4 SQL server enterprise core pack (1 core pack for 2 vCPU)
34
SQL instance configurations was set to correspond application needs. Each instance
could host more than one application database depending on the resource usage. If da-
tabases used a lot of resources, then they were placed on different instances.
Figure 27. SQL cluster
The cluster was made as active-passive cluster. This enabled the more effective use of
licensing model. Since SQL Microsoft license active cores, having 4 license packs were
enough to license the active server cores. With the AAG configuration SQL high availa-
bility was achieved. Since the database is always queried by listener address the query
itself would get forwarded on the active node where the active database would locate.
Then the active database would get replicated to the passive node having the same data
always on both nodes. This enabled also more flexible maintenance windows since the
databases would always be on. [25]
35
5 PROJECT IMPLEMENTATION, FINALIZING
After the first phase of implementation the cooling period of three weeks was held. During
this time no project work was done apart from monitoring the situation. Feedback was
collected from user and workstation migrations. The results showed that there had been
problems with users who were migrated on remote locations. Most of the workstation
migrations got failed in said scenario. Some file share accesses were failing too. User
migrations, however, were successful.
During the first phase of project implementation the underlaying infrastructure was suc-
cessfully modernized and migrated. The project regarding server migrations were suc-
cess. Only servers missing migrations were application servers. Due to complex envi-
ronment some of the servers needed to remain in their old domains. This was already
mapped in the beginning of the project so that the situation was acceptable. The remain-
ing servers would be migrated once all relations to old domains were purged.
5.1 Application Server Migrations
Application servers were the most complex ones to migrate and therefore split into two
main groups, business-critical and non-business critical. Non-critical ones had the appli-
cations that had less impact on business and were less likely to fall apart. Servers in the
group got migrated one by one with constant monitoring using the same method as de-
scribed in section 4.4.
The business-critical servers were divided to three groups.
• Alarm Receiving Center servers
ARC applications, Innovative Security Manager (ISM), SMS receivers, Cisco Uni-
fied Contact Center Express (Cisco CCX), video surveillance
• Remote Operations servers
crime alarming, fire alarming, door alarming, physical access control
• CCTV servers
Surveillance camera system, video recorders
All the servers were migrated the same way as described in section 4.4. The challenge
with the application servers was the right order for migrations more than the technical
36
aspect of the migrations. No production and business were to be disturbed. Since the
servers had primary and secondary server, they were migrated secondary servers first.
After all secondary servers were migrated the break was commenced. During the pause
systems were inspected and discovered functional. Once everything was noted compli-
ant all the primary servers were migrated. After migration systems were carefully moni-
tored and found the tasks successfully completed. Using this procedure, the business
was able to continue operations incessantly.
5.2 Workstation Migrations
The remaining computer that failed with automated migration scripts were finalized man-
ually. Number of scripts and different csv files had to be made which needed to be run
manually each. It turned out that remotely migrated computers failed due to network is-
sues. Reasoning behind this was the lack of domain connection during reboot. To over-
come this the separate FortiClient Enterprise Management Server (EMS) was installed
and corresponding FortiClient VPN client was installed on computers. This enabled re-
mote workstations to establish the connection to domain.
Workstations were migrated with the number of scripts. The first thing that needed to be
done was to move the computers to right OU. As a preparation a csv-file needed to be
made of the workstations to be moved. The script below illustrates the usage of csv-file,
adding the computers to group and then moving the workstations to right OU.
$csv = "3 admt AVARN to era 2.csv" $list = import-csv -path C:\asennus\csv\$csv $OU = "OU=MigrateToArok,OU=Devices,OU=AVARN,DC=ad,DC=avarn,DC=fi" $group = "MigrateToArok" foreach ($item in $list) { $computer = get-adcomputer $item."device-name" $computerDN = Get-ADCom-puter $computer -Properties distinguishedname | select -expandproperty distin-guishedname Move-ADObject -Identity $computerDN -targetpath $OU $computer_added = ADD-ADGroupMember -identity $group -members $computer }
After the script was run on all needed scenarios then the whole list of workstations in the
migration OU was created with the script below.
37
$csv = "MigrateToArok_OU_haaran_koneet.csv" $OU = "OU=MigrateToArok,OU=Computers,OU=PREVENT360,DC=PRE-VENT360,DC=biz" $export = Get-ADComputer -filter * -SearchBase $OU $export | export-csv c:\asennus\csv\$csv -append -notypeinformation -delimiter "," -encoding UTF8
Once this was done the the Forensit profwiz wizard was run against the workstations.
The scripts in appendices 3 and 4 were a little bit tweaked to respond the correct OUs of
the computers. Otherwise the script remained same. On this occasion the migrations
were successful due to more manual work and EMS server with the new VPN client. In
the end the workstations were moved to a corresponding OU, depending their naming
as seen on the script below.
$list = get-adcomputer -SearchBase "OU=Migrated from Prevent,OU=Comput-ers,OU=AROK,DC=arok,DC=fi" -filter * $OU_Laptop = "OU=Laptops,OU=Computers,OU=AROK,DC=arok,DC=fi" $OU_Desktop = "OU=Workstations,OU=Computers,OU=AROK,DC=arok,DC=fi" $group = "sg_GP_Remove_TempAdmin" foreach ($item in $list) { $computer = get-adcomputer $item.samaccountname $computer_added = ADD-ADGroupMember -identity $group -members $com-puter } foreach ($item in $list) { $computer = get-adcomputer $item.samaccountname | select -ExpandProperty samaccountname $computerDN = Get-ADComputer $computer -Properties distinguishedname | se-lect -expandproperty distinguishedname if($computer -like "L-*") {Move-ADObject -Identity $computerDN -targetpath $OU_Laptop} elseif($computer -like "D-*") {Move-ADObject -Identity $computerDN -targetpath $OU_Desktop} elseif($computer -like "PRELT*") {Move-ADObject -Identity $computerDN -targetpath $OU_Laptop} elseif($computer -like "PREWS*") {Move-ADObject -Identity $computerDN -targetpath $OU_Desktop} else {write-host "$computer ei ole listattu"} } $list1 = get-adcomputer -SearchBase "OU=Migrated from Avarn,OU=Comput-ers,OU=AROK,DC=arok,DC=fi" -filter * $OU_Laptop = "OU=Laptops,OU=Computers,OU=AROK,DC=arok,DC=fi" $OU_Desktop = "OU=Workstations,OU=Computers,OU=AROK,DC=arok,DC=fi" foreach ($item in $list1)
38
{ $computer = get-adcomputer $item.samaccountname $computer_added = ADD-ADGroupMember -identity $group -members $com-puter } foreach ($item in $list1) { $computer = get-adcomputer $item.samaccountname | select -ExpandProperty samaccountname $computerDN = Get-ADComputer $computer -Properties distinguishedname | select -expandproperty distinguishedname if($computer -like "L-*") {Move-ADObject -Identity $computerDN -targetpath $OU_Laptop} elseif($computer -like "D-*") {Move-ADObject -Identity $computerDN -targetpath $OU_Desktop} elseif($computer -like "PRELT*") {Move-ADObject -Identity $computerDN -targetpath $OU_Laptop} elseif($computer -like "PREWS*") {Move-ADObject -Identity $computerDN -targetpath $OU_Desktop} else {write-host "$computer ei ole listattu"} }
39
6 DISCUSSIONS AND CONCLUSIONS
The objective of this thesis was to deliver a modernized information technology infra-
structure while merging and migrating users, workstations and servers from seven do-
mains into one main domain. While aiming for a stabilized state infrastructure the priority
was to achieve a state where the company IT-environment was secure, standardized
and efficiently managed.
In nowadays business world it is quite common that companies acquire other companies
and then get merged. During the last couple of years Avarn Security had gone through
numerous company acquisitions. During the business merges IT-functions were not mi-
grated properly if at all and the IT-environment was in a state of becoming seriously
complex and extremely hard to manage. The situation was not cost effective either.
During the project some out of scope processes were also created which reinforced the
actual outcome of the whole migration and modernization. The lack of ITSM processes
was almost a showstopper at the beginning. With creative and agile way of working the
processes were created on the go and are used in daily routines ever since. Some other
adversities were solved on the way which were close to impossible to foresee. First, the
current state of world in the middle of Covid-19 had caused some challenges. Most of
the office workers were working from remote locations which resulted in some unfore-
seen errors in automated processes. Human factor was also causing a bit of a challenge.
The project team had false assumptions of the competence of regular users. This led to
communications and instructions to be rather poor during the first phase. Users were
simply unaware of what the migration meant and that what account they should have
used after the migrations. This caused a lot of false errors regarding email functionality.
It cannot be stressed out enough how important a proper user instruction and communi-
cation is.
Server migrations were much needed and when all the servers were brought mainly in
one domain the cost effectiveness was notable. Not only it was possible to save in re-
sources but also in management costs. Everything was brought under one umbrella
hence everything was brought under the same tools and processes. Full-Time Equiva-
lent (FTE) was reduced in half of what it was before migrations. As a result, the infra-
structure was admittedly modernized, and it was corresponding to best practises pro-
cesses and standards. The whole environment was brought to a state of next level to
40
follow the company strategy. One of the major benefits following the project was the time
usage of the IT-personnel. After the project IT-team had more time to actually be what is
it supposed to be, the support functions of the business. This means that every IT-per-
sonnel had now more time to help business to gain advantage of the technology the
company had.
Figure 28. Environment after project
Once the project was done the environment was in the state illustrated in Figure 28.
Users, workstations and servers were positioned within three domains as planned and
the domains were corresponding to business. Cash-domain was for Avarn Cash Solu-
tions, ARC-domain was for personnel of the alarm receiving center and all other users
were placed in arok-domain. Arok-domain was a hybrid environment with services from
Azure and O365. All the applications were functional and there were hardly any interrup-
tions to business during the project.
The project work could be taken also further and what was already done can act as a
firm groundwork. As it was stated in this thesis the network is quite complex and would
require a lot of work to be streamlined. Simplifying and modernizing the network would
be a major step towards intelligent networks now when all the other infrastructure is sup-
porting it. This project could also be split in different parts and could be individual projects
41
of each parts. That would enable a more precise project on each element and the project
could go deeper within the area. After all this project was done more on a higher level.
All in all, the outcome of the whole project can be considered as a huge success. As a
result of the thesis the infrastructure was modernized to correspond best practises, pro-
cesses and standards. Upon finalizing this thesis the infrastructure was advanced to a
level where next steps could be taken towards outsourcing and cloud based strategy.
References
1 https://docs.microsoft.com/en-US/troubleshoot/sql/admin/considerations-au-togrow-autoshrink
2 https://www.prajwaldesai.com/sccm-2012-r2-step-by-step-guide/
3 https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/configu-ration-manager-current-branch-antivirus-exclusions/ba-p/884831
4 https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model
5 https://docs.microsoft.com/en-us/exchange/new-features/updates?view=ex-chserver-2016
6 https://docs.microsoft.com/en-us/mem/configmgr/core/servers/manage/introduc-tion-to-reporting
7 https://docs.microsoft.com/en-us/mem/configmgr/core/servers/deploy/config-ure/configure-role-based-administration
8 https://docs.microsoft.com/en-us/mem/configmgr/core/servers/deploy/config-ure/boundaries
9 https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/over-view
10 https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
11 https://docs.microsoft.com/en-us/mem/configmgr/core/servers/manage/configur-ing-reporting
12 https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/ac-counts
13 https://www.cyberark.com/what-is/least-privilege/#:~:text=The%20princi-ple%20of%20least%20privilege%20(PoLP)%20refers%20to%20an%20infor-mation,perform%20his%2Fher%20job%20functions.
14 https://docs.microsoft.com/en-us/mem/configmgr/core/clients/deploy/about-client-settings
15 https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierar-chy/ports
16 https://docs.microsoft.com/en-us/windows/release-health/release-information
17 Justin Hall, Microsoft, ADMT Guide: Migrating and Restructuring Active Directory Domains, 2014, https://www.microsoft.com/en-us/download/confirma-tion.aspx?id=19188.
18 https://social.technet.microsoft.com/wiki/contents/articles/43908.active-directory-migration-checklist.aspx
19 https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains
20 https://docs.microsoft.com/en-us/mem/configmgr/core/clients/man-age/cmg/server-auth-cert
21 https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/setup-cloud-management-gateway
22 https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/repli-cation/active-directory-replication-concepts
23 https://blog.it-koehler.com/en/Archive/2951
24 https://docs.microsoft.com/en-gb/sysinternals/downloads/adinsight
25 https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/win-dows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15
Appendix 1
1 (1)
AD objects, arok domain
• Organizational units 57 pcs
• AD sites 2 pcs
• Group Policies 54 pcs
• User groups 1144 pcs
o Security/Domain Local 1051 pcs
o Security/Global 54 pcs
o Security/Universal 37 pcs
o Distribution groups 2 pcs
• 595 groups empty
• 814 user accounts
o enabled 751 users
o disabled 63 users
o 130 users with non-expiring password, which of 119 enabled users
• Workstations 410 pcs
o enabled 408 pcs
o disabled 2 pcs
• Servers 140 pcs
o enabled 138 pcs
o disabled 2 pcs
• users – disabled – 180 days without log in – 37 pcs
• users – disabled – 1 year without log in – 28 pcs
• users – disabled – 2 years without log in – 26 pcs
• users – enabled - 180 days without log in – 297 pcs
• Users – enabled – 1 year without log in – 244 pcs
• Users – enabled – 2 years without log in – 228 pcs
• Workstations – disabled – 180 days without log in – 3 pcs
• Workstations – disabled – 1 year without log in – 3 pcs
• Workstations – disabled – 2 years without log in – 0 pcs
• Workstations – enabled – 180 days without log in – 76 pcs
• Workstations – enabled – 1 year without log in – 32 pcs
• Workstations – enabled – 2 years without log in – 0 pcs.
Appendix 2
1 (3)
Forensit profwiz parameters
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ForensiTUserProfileWizard xmlns="http://www.ForensiT.com/schemas">
<Parameters>
<!-- ForensiT User Profile Wizard run options -->
<!-- Note: options set here are overridden by parameters passed on the command line
-->
<Domain>arok</Domain>
<AdsPath>OU=Migrated_from_Avarn,OU=Comput-
ers,OU=AROK,DC=arok,DC=fi</AdsPath>
<Azure></Azure>
<AzureObjectIDFile></AzureObjectIDFile>
<ForceJoin>False</ForceJoin>
<NoJoin>False</NoJoin>
<NoDefault>False</NoDefault>
<Delete></Delete>
<Disable></Disable>
<UnJoin>False</UnJoin>
<Workgroup></Workgroup>
<ForceRoamingOption></ForceRoamingOption>
<!-- Credentials -->
<DomainAdmin>arok\Forensit</DomainAdmin>
<DomainPwd>**** </DomainPwd>
<LocalAdmin>ad\Forensit</LocalAdmin>
<LocalPwd>**** </LocalPwd>
<SetsIDHistory>False</SetsIDHistory>
<OldDomainAdmin></OldDomainAdmin>
<OldDomainPwd></OldDomainPwd>
<Key>****</Key>
<!-- Corporate Edition Settings -->
<Silent>False</Silent>
<NoMigrate>False</NoMigrate>
Appendix 2
2 (3)
<NoReboot>False</NoReboot>
<RemoveAdmins>False</RemoveAdmins>
<MachineLookupFile></MachineLookupFile>
<Log>C:\Users\Public\Documents\Migrate.Log</Log>
<!-- Script Settings -->
<RunAs>\\S-SCCM\ForensitAvarnMigration$\Forensit_Fol-
low_On_Script_V1.0.ps1</RunAs>
<Hash>****</Hash>
<RunScriptPerUser>False</RunScriptPerUser>
<RunAsSystem></RunAsSystem>
<!-- Settings for migrating all profiles -->
<All>True</All>
<OldDomain>AD</OldDomain>
<UserLookupFile>\\S-SCCM\ForensitAvarnMigration$\Forensit_Avarn-Arok_Us-
ers.csv</UserLookupFile>
<Exclude>ASPNET,Administrator,defaultuser0</Exclude>
<!-- Advanced Settings -->
<Persist>False</Persist>
<NoGUI>True</NoGUI>
<SkipOnExistingProfile>False</SkipOnExistingProfile>
<SkipOnDisabledAccount>False</SkipOnDisabledAccount>
<SkipOnNoUserLookup>False</SkipOnNoUserLookup>
<FailOnMachineNameNotFound>False</FailOnMachineNameNotFound>
<UseExistingComputerAccount>False</UseExistingComputerAccount>
<ServicePath></ServicePath>
<RenameProfileFolder>False</RenameProfileFolder>
<ProtocolPriority></ProtocolPriority>
<DC></DC>
<CopyProfile>False</CopyProfile>
<DeepScan>1</DeepScan>
<!-- Outlook Settings -->
Appendix 2
3 (3)
<ZeroConfigExchange>False</ZeroConfigExchange>
<!-- VPN Settings -->
<VPN>False</VPN>
<DefaultUserPwd></DefaultUserPwd>
</Parameters>
<!-- Script Settings - do not edit -->
<ScriptLocation>C:\ProgramData\ForensiT\User Profile Wizard Corporate\Deployment
Files\From Avarn to Arok v1.2\Migrate-From Avarn to Arok v1.2.ps1</ScriptLocation>
<CopyScript>True</CopyScript>
<System></System>
<!-- Licensing Information -->
<licensing>*****</licensing>
</ForensiTUserProfileWizard>
Appendix 3
1 (4)
Master script prevent360 to arok
# Functions
function Set-XMLAttributeValue
{
param ([Parameter(Mandatory=$true)][string]$XML, [Parameter(Manda-
tory=$true)][string]$Attribute, [Parameter(Mandatory=$true)][string]$Value)
$Search = "<$Attribute>"
$Start = $XML.IndexOf($Search)
If($Start -eq -1){
return $XML
}
$End = $XML.IndexOf("</$Attribute>")
$Pre = $XML.Substring(0, $Start + $Search.Length)
$Post = $XML.Substring($End)
$New = $Pre + $Value + $Post
return $New
}
function Get-XMLAttributeValue
{
param ([Parameter(Mandatory=$true)][string]$XML, [Parameter(Manda-
tory=$true)][string]$Attribute)
$Search = "<$Attribute>"
$Start = $XML.IndexOf($Search)
If($Start -eq -1){
return
}
$End = $XML.IndexOf("</$Attribute>")
$Value = $XML.Substring($Start + $Search.Length, $End - ($Start +
$Search.Length))
return $Value
Appendix 3
2 (4)
}
function CopyLocal{
# Copy the migration files locally to C:\ProgramData\ForensiT\Migrate
$TargetFolder = [Environment]::GetFolderPath([Environment+SpecialFolder]::Com-
monApplicationData) + "\\ForensiT\\Scripting"
New-Item -Path $TargetFolder -ItemType directory -Force | Out-Null
Copy-Item ".\Profwiz.exe" "$TargetFolder\\Profwiz.exe"
$Config = [String](Get-Content -Path ".\Profwiz.config" -Raw)
# User lookup file
$Value = Get-XMLAttributeValue $Config "UserLookupFile"
If(-Not [string]::IsNullOrEmpty($Value)){
$LookFile = Split-Path $Value -leaf
$Config = Set-XMLAttributeValue $Config "UserLookupFile" $LookFile
Copy-Item $Value "$TargetFolder\\$LookFile"
}
# Device Lookup File
$Value = Get-XMLAttributeValue $Config "MachineLookupFile"
If(-Not [string]::IsNullOrEmpty($Value)){
$LookFile = Split-Path $Value -leaf
$Config = Set-XMLAttributeValue $Config "MachineLookupFile" $LookFile
Copy-Item $Value "$TargetFolder\\$LookFile"
}
# Follow-0n File
$Value = Get-XMLAttributeValue $Config "RunAs"
If(-Not [string]::IsNullOrEmpty($Value)){
$LookFile = Split-Path $Value -leaf
$Config = Set-XMLAttributeValue $Config "RunAs" $LookFile
Copy-Item $Value "$TargetFolder\\$LookFile"
}
Appendix 3
3 (4)
# Azure ID File
$Value = Get-XMLAttributeValue $Config "AzureObjectIDFile"
If(-Not [string]::IsNullOrEmpty($Value)){
$LookFile = Split-Path $Value -leaf
$Config = Set-XMLAttributeValue $Config "AzureObjectIDFile" $LookFile
Copy-Item $Value "$TargetFolder\\$LookFile"
}
# Write the updated config file
Set-Content -Path "$TargetFolder\\Profwiz.config" -Value $Config -Force
return $TargetFolder
}
#Set variables in this section
#Enter the flag file name
$MachineFlagName="ForensiTMigrated"
#Set $Debug to true to see debug messages
$Debug=$true
$CopyLocal = $false
# This script will write a flag file if it has already been run successfully. Here we check if
the flag file exists.
$FlagFile = [Environment]::GetFolderPath([Environment+SpecialFolder]::Applica-
tionData) + "\" + $MachineFlagName
If(Test-Path -Path $FlagFile){
if($Debug) {
$delete = Read-Host "The 'migrated' flag file has been set. Do you want to delete
the flag file and continue? (Y/n)"
Appendix 3
4 (4)
if($delete -eq '' -Or $delete -eq 'Y' -Or $delete -eq 'Yes'){
Remove-item $FlagFile
}
else{
exit
}
}
else{
exit
}
}
if($CopyLocal){
$TargetFolder = CopyLocal
}
else
{
$TargetFolder = $PSScriptRoot
}
# Call Profwiz.exe and wait for it to finish
$profwiz = Start-Process -FilePath "$TargetFolder\\Profwiz.exe" -ArgumentList "/RE-
BOOTDELAY 30" -Wait -PassThru
$profwiz.WaitForExit();
# If Profwiz.exe does not return an error, write a flag file to prevent this script being run
twice
if ($profwiz.ExitCode -eq 0) {
New-Item -Path $FlagFile -ItemType File| Out-Null
}
else{
Write-Warning "$_ exited with status code $($profwiz.ExitCode)"
}
# Cleanup
if($CopyLocal){
Remove-item $TargetFolder -Recurse
}
Appendix 4
1 (4)
Master script ad.avarn to arok
# Internal script variables DO NOT change
$Filter = $null
$LookupFile = $null
$Reboot = $false
#########################################################################
#############################################
# Set your script variables here
# Uncomment the filter that you want to use
#$Filter = "LocalSids"
$Filter = "DomainSids"
#$Filter = "AzureSids"
#If you are filtering by Domain SIDs, set the domain RID for your domain
$DomainRID = "S-1-5-21-1525874564-572990756-2040194385"
# Set $PassByFolderName to $True to migrate using the profile folder
name, or $False to migrate using the user Sid
$PassByFolderName = $True
# If you want to use a lookup file, specify that here
#$LookupFile = ".\Users.csv"
#########################################################################
#############################################
# Functions
# The function requires the csv file to have a header: Oldname,NewName
function Get-NewNameFromLookupFile
{
param ([Parameter(Mandatory=$true)][string]$LookupFile, [Parame-
ter(Mandatory=$true)][string]$OldName)
$Header = 'OldName', 'NewName'
$lookup = import-csv $lookupFile -Header $Header
ForEach ($row in $lookup){
Appendix 4
2 (4)
if($($row.OldName) -eq $oldName)
{
return $($row.NewName)
break
}
}
}
#########################################################################
#############################################
if($Filter -eq $null){
Write-Warning "You need to edit this script to configure your migra-
tion settings before it can be run."
exit
}
if(($Filter -eq "DomainSids") -and ($DomainRID -eq $null)){
Write-Warning "Domain RID has not been set."
exit
}
# We can filter local accounts by getting the SID for the Administrator
account, and finding the RID
$AdminSID = (Get-LocalUser | Where-Object {$_.SID -like 'S-1-5-*-
500'}).SID
$LocalMachineRID = $AdminSID.Value.subString(0, $AdminSID.Value.Length -
4)
#Enumerate profiles in the registry
$keys = Get-ChildItem -Path 'Registry::HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList'
foreach ($key in $keys) {
$sid = $key.PSChildName
Appendix 4
3 (4)
# Filter out System SIDs and Administrator accounts
if(($sid.Length -eq 8) -Or ($sid -Like 'S-1-5-80-*') -Or ($sid -Like
'*-500')){
continue
}
if($Filter -eq "LocalSids"){
# Filter on local accounts
if($sid -NotLike $LocalMachineRID +'*'){
continue
}
}
elseif($Filter -eq "DomainSids"){
# Filter on domain RID
if($sid -NotLike $DomainRID +'*'){
continue
}
}
elseif($Filter -eq "AzureSids"){
# Filter on Azure SIDs
if($sid -NotLike 'S-1-12-*'){
continue
}
}
# Get the profile folder name
$profileImagePath = (Get-ItemProperty -Path Registry::$key).ProfileI-
magePath
$profileName = Split-Path $profileImagePath -leaf
if($PassByFolderName -eq $True){
$SourceAccount = $profileName
$ParmeterList = "/SOURCEPROFILE $SourceAccount /TARGETACCOUNT
$newUserName /NOREBOOT"
}
else{
$SourceAccount = $Sid
$ParmeterList = "/SOURCEACCOUNT $SourceAccount /TARGETACCOUNT
$newUserName /NOREBOOT"
}
Appendix 4
4 (4)
# Remove any suffix from the folder name
$_Temp = $profileName.split(".")
if(-Not $_Temp[0] -eq ""){
$LookupName = $_Temp[0]
}
else{
$LookupName = $profileName
}
# Get new user name if we are using a lookup file
$newUserName = $null
if($LookupFile -ne $null){
$newUserName = Get-NewNameFromLookupFile $LookupFile $LookupName
}
# If we don't have a new name, use the current name
if($newUserName -eq $null){
$newUserName = $LookupName
}
# Call Profwiz.exe...
$profwiz = Start-Process -FilePath "./Profwiz.exe" -ArgumentList
$ParmeterList -wait -PassThru
#... and wait for it to finish
$profwiz.WaitForExit();
# If there is an error print it
if ($profwiz.ExitCode -ne 0) {
Write-Warning "$_ exited with status code $($profwiz.ExitCode)"
}
else{
$Reboot = $true
}
}
#Reboot the machine
if($Reboot -eq $true){
Restart-Computer
}