IT-infrastructure Migration and Modernization - Theseus

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>





<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>



<DomainAdmin>arok\Forensit</DomainAdmin>

<DomainPwd>**** </DomainPwd>

<LocalAdmin>ad\Forensit</LocalAdmin>

<LocalPwd>**** </LocalPwd>

<SetsIDHistory>False</SetsIDHistory>

<OldDomainAdmin></OldDomainAdmin>

<OldDomainPwd></OldDomainPwd>

<Key>****</Key>



<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>



<RunAs>\\S-SCCM\ForensitAvarnMigration$\Forensit_Fol-

low_On_Script_V1.0.ps1</RunAs>

<Hash>****</Hash>

<RunScriptPerUser>False</RunScriptPerUser>

<RunAsSystem></RunAsSystem>



<All>True</All>

<OldDomain>AD</OldDomain>

<UserLookupFile>\\S-SCCM\ForensitAvarnMigration$\Forensit_Avarn-Arok_Us-

ers.csv</UserLookupFile>

<Exclude>ASPNET,Administrator,defaultuser0</Exclude>



<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>

Appendix 2

3 (3)

<ZeroConfigExchange>False</ZeroConfigExchange>



<VPN>False</VPN>

<DefaultUserPwd></DefaultUserPwd>

</Parameters>



<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>*****</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"



$Config = Set-XMLAttributeValue $Config "MachineLookupFile" $LookFile


}

# Follow-0n File

$Value = Get-XMLAttributeValue $Config "RunAs"



$Config = Set-XMLAttributeValue $Config "RunAs" $LookFile


}

Appendix 3

3 (4)

# Azure ID File

$Value = Get-XMLAttributeValue $Config "AzureObjectIDFile"



$Config = Set-XMLAttributeValue $Config "AzureObjectIDFile" $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

}

IT-infrastructure Migration and Modernization - Theseus

Documents

Transcript of IT-infrastructure Migration and Modernization - Theseus