How a small experiment with Claude Code grew into an identity operations platform and changed the way I think about AI-assisted software development.

I didn’t set out to build an identity platform.

During my New Year break, I started experimenting more seriously with Claude Code. At the same time, I had a recurring problem in my day-to-day work that had been bothering me for years.

Whenever I wanted to review access across our environment, I had to jump between multiple systems, export data, compare spreadsheets, check HR information, cross-reference the corporate directory, and manually work out who was who.

Most applications knew very little about the person behind an account. They might have an email address and a full name, but not necessarily the person’s department, job title, employment type, manager, or even whether that person still worked for the company.

So a seemingly simple question such as “Does this person still need access to this system?” could require several data sources and a surprising amount of manual work.

My original goal was simple: bring the information together so I could spend less time collecting data and more time deciding what actually needed attention.

Eight months later, that small experiment had grown into a platform that pulls together identity and access information from dozens of systems, models thousands of entities and tens of thousands of relationships, and continuously checks the environment for inconsistencies.

The surprising part was not how quickly AI helped me write the code.

It was how much work it still took to make the result something I could actually trust.

The first version was much smaller

My first idea was almost embarrassingly simple: pull users from our main identity sources and a few applications, match them mostly by email address, and show where each person had an account.

At the time, I was still discovering what Claude Code could realistically do, and I was thinking about the problem mainly as user management. I wasn’t thinking about identity graphs, reconciliation engines, expected state, or governance workflows. I just wanted to stop opening the same systems and spreadsheets over and over again.

The first version saved time immediately, but as I connected more systems, the model began to break down.

Users were only one part of the picture.

Groups mattered because they granted access. Then there were shared mailboxes, service accounts, shared accounts, applications, and other resources that were not “users” but still mattered when evaluating access. Contractors, partners, external providers, and other identities also didn’t always exist in the same authoritative systems as employees.

The question was no longer simply:

Where does this user exist?

It became:

What is this identity connected to, what does it own, what does it have access to, and why?

That was when I restructured Identity Hub around entities and relationships rather than users.

A person could be an entity. So could a group, application, organization, shared resource, or service account. Relationships could represent membership, ownership, management, access, delegation, or affiliation.

What started as an easier way to search across systems gradually became a model of how identities actually moved through the organization.

Reality is messier than the data model

One of the most important lessons came from something that sounds obvious in hindsight: rarely does one system know the whole truth.

HR may be authoritative for employees, but some contractors may not exist there at all. An application may know whether an account is enabled while knowing almost nothing about the human behind it. Another source may understand the person’s organizational context but know nothing about their application access.

And then there are exceptions.

Early in the project, I created a Knowledge Base inside Identity Hub to capture organizational context that otherwise existed only in my head: which sources mattered, which populations should be treated differently, what exceptions existed, and why some apparently unusual situations were actually valid.

I also used that context when working with Claude. Before adding an integration, I would have it review the relevant business logic and API documentation, identify the data we needed, and go through the design with me before implementation.

That worked well, but it eventually exposed an important limitation.

Documentation can explain the rules. Code has to enforce them.

A deterministic system cannot depend on whether an AI model happens to interpret a paragraph correctly in a particular session. Important business rules like source authority, precedence, matching logic, lifecycle state, and exception handling had to become explicit software behavior.

That realization changed the way I approached the project.

A successful sync can still be wrong

The early versions produced results quickly, which was exactly what I wanted from a side project. They also produced technical debt quickly.

As the system expanded, I began finding situations where the data looked correct at first glance but wasn’t. Some edge cases had not been considered. Some integrations made perfectly reasonable assumptions that did not apply in our environment. Sometimes correcting one issue exposed another.

Eventually, I realized fixing individual bugs wasn’t enough. I needed stronger guarantees about the system’s behavior.

An API request returning HTTP 200 was not enough.

A sync job completing successfully was not enough.

Even a sync with zero reported errors could still leave me with an inaccurate representation of reality.

Imagine an account that is still active inside an application after the person behind it has left the company. The application itself may be perfectly correct: as far as it knows, the account exists and is enabled. HR may also be correct in showing that the employment relationship has ended. The corporate directory may correctly show the primary identity as disabled.

None of those systems is necessarily wrong.

The problem exists between them.

It only becomes visible once enough context is correlated to ask a different question: not “Did the API return the account?” but “Does the state of this account still make sense?”

That distinction became central to Identity Hub.

The goal became determinism. If nothing had changed in a source system, running the same synchronization twice should not generate artificial changes. The order in which APIs returned data should not affect the resulting state. Partial datasets should not accidentally cause valid information to disappear, and a non-authoritative system should not overwrite an authoritative attribute simply because it returned a value.

Most importantly, when the system encountered something it could not safely understand, it should fail conservatively rather than confidently invent an answer.

The biggest risk was no longer that the software would crash.

It was that it would keep running while giving me false confidence.

Trust had to be earned

I did not start trusting Identity Hub because the test suite passed.

Trust accumulated slowly.

Because I knew the underlying systems well, I could repeatedly compare the platform’s conclusions with the actual sources, especially for unusual identities, lifecycle states, ownership relationships, and access patterns.

Testing also became much more deliberate. Instead of asking AI to implement large areas of functionality in one go, I moved toward smaller phases: research, design, implementation, testing, review, then the next step.

I also separated review concerns. Rather than expecting one large AI context to implement a feature and then judge its own work, I began doing focused reviews for bugs, security, documentation consistency, business-rule alignment, and edge cases.

Over time, what had started as experimentation became a repeatable engineering process.

That led me to one of the broader lessons I took from the project:

The faster code can be produced, the more disciplined we need to become about what we produce.

AI dramatically reduces the cost of creating an implementation. It does not remove the cost of understanding whether that implementation is correct.

In some ways, it makes that distinction more important.

From manual reviews to continuous assurance

The original goal of Identity Hub was to save time, and it did that almost immediately. Once I began trusting the data, however, the value changed.

Previously, a broad access review could require hours of preparation, sometimes much longer depending on the scope. Before investigating anything, I first had to gather information from multiple sources, determine whether it was consistent, identify who the accounts belonged to, and reconstruct enough context to understand what I was looking at.

Now most of that correlation happens continuously.

Instead of compiling the information, I can look directly at findings: an offboarded person who still has active access, an account that cannot reliably be mapped back to a person, access left behind after a role change, conflicting attributes between authoritative systems, orphaned shared or service accounts, unexpected memberships, or discrepancies between HR, directory, and application state.

These are not theoretical categories. They are the kinds of issues that began surfacing once enough information could be correlated reliably.

The biggest change, then, was not simply speed. It was the operating model.

Checks that were previously periodic because they were expensive and repetitive could now happen continuously because the underlying systems synchronized throughout the day.

I moved from collecting and comparing information to deciding what actually required intervention.

That is much closer to continuous assurance than a traditional manual access review.

Actual state is not enough

Once the system could describe actual access reliably, another question became unavoidable:

What should someone have?

That led me to model expected access patterns based on factors such as role, department, location, and employment type, not as rigid templates, but as baselines against which meaningful deviations could be detected.

That distinction matters for more than reporting.

Without an expected state, automation is simply execution.

If a system is eventually going to provision or remove access safely, it first needs a reliable definition of what “correct” is supposed to look like.

And once automation begins to affect production access, the consequences of being wrong change significantly.

A read-only system can produce an incorrect finding. A write-enabled identity system can make an incorrect change.

For that reason, my goal is not maximum automation. It is maximum safe automation.

The principle I keep coming back to is simple:

Known, approved, and deterministic: automate it.

Ambiguous, exceptional, or privileged: keep a human in the loop.

In some cases, the right intermediate step may be one-click remediation rather than full automation. Approvals can continue to happen through existing workflow systems while Identity Hub acts as the governance and execution layer behind them.

And automation should not simply act. It should verify afterward that the resulting state matches what was intended.

What Claude Code actually changed

Because Claude Code was involved from the beginning, there is an obvious question:

Did I build Identity Hub, or did the AI build it?

Claude removed an enormous amount of mechanical work between an idea and working software. It wrote code, researched approaches, implemented designs, created tests, and helped review results.

Without that leverage, I almost certainly would not have attempted a project of this scale on my own.

But Claude did not decide what Identity Hub should become.

It did not know how the organization worked until I explained it. It did not know which system should be authoritative in a particular situation. It could not decide which inconsistencies mattered operationally, what level of risk was acceptable, or whether a technically elegant implementation actually reflected reality.

Those decisions remained mine.

At different stages, I found myself thinking like a product owner, architect, project manager, security reviewer, QA engineer, development lead, and operator.

The most useful skill I developed was not “prompt engineering.”

It was learning how to collaborate with AI critically.

AI can make assumptions with enormous confidence. It can build an elegant implementation around an incorrect interpretation. It can miss an edge case that someone with years of operational experience recognizes immediately.

And because the output arrives so quickly, it is surprisingly easy to mistake visible progress for understanding.

The more capable the AI became, the less willing I became to accept its output at face value.

In that sense, working with AI became surprisingly similar to working with people. You learn what context needs to be explicit, what can safely be delegated, where review matters most, and when you need to challenge an answer that looks convincing.

What changed in the way I build

The project changed not only what I built, but how I approach building software with AI.

If I started again today, I would spend more time on design before implementation.

AI makes visible progress incredibly easy. You describe something and minutes later there is a working screen, API endpoint, migration, or integration. That feedback loop is powerful, but it can also encourage implementation to move faster than understanding.

Some of the most expensive changes I made later could have been avoided by thinking more deeply about the model earlier.

I would also work incrementally from the beginning. Large AI-assisted implementations create large contexts, large review surfaces, and more opportunities for hidden assumptions to survive unnoticed. Smaller phases are easier to understand, test, and challenge.

Most importantly, I would ask more questions before asking for code.

Why should this source win?

What exactly does “inactive” mean here?

What happens if an API returns only part of the expected dataset?

What assumptions are we making about identity matching?

If a sync succeeds, how do we know the resulting state is correct?

Those questions turned out to be far more valuable than simply asking whether the code worked.

AI changes build vs. buy. It does not eliminate it.

There is one conclusion I would not want anyone to take from this project:

Just because AI makes custom software easier to build does not mean we should build everything ourselves.

Mature commercial identity governance products exist for good reasons. Custom software creates responsibilities around security, architecture, testing, maintenance, documentation, resilience, and long-term ownership.

Being able to build something is not, by itself, a reason to build it.

What AI changes is the economics of the decision.

A domain expert can now realistically explore and build focused internal software that might previously have required a dedicated development team. That becomes particularly interesting when the problem is highly specific to how an organization operates.

Identity Hub creates value because it can model details, relationships, and exceptions specific to the surrounding environment.

But that flexibility is not free. Every custom rule becomes something that must be understood, tested, maintained, and eventually handed over.

I wouldn’t suggest that every company build its own identity platform.

We should revisit some assumptions about where custom internal engineering can create disproportionate value.

The build-versus-buy question still exists.

AI moves the line.

The part that matters most

Identity Hub started because I was tired of doing a repetitive task manually.

It grew because every improvement created another possibility. Better correlation enabled better checks. More reliable data enabled safer automation. Turning knowledge that existed in people’s heads into explicit rules made the entire system more useful.

It also became one of the most valuable learning projects I have worked on. I had to understand software architecture, data modeling, testing, security, product design, and engineering discipline more deeply than I had before.

When I started, the most impressive thing about AI-assisted development was how quickly it could produce code.

That is no longer the part I find most interesting.

The hard part is understanding the problem deeply enough to know what to build. It is turning implicit knowledge into explicit rules, identifying the assumptions hiding inside apparently obvious requirements, designing for what happens outside the happy path, and deciding where automation is safe and where human judgment still matters.

Ultimately, the difficult question is not whether the system in front of you works.

It is whether you have enough reason to trust that it is telling you the truth.

Identity Hub has been my clearest example of that so far.

The code came fast. Trust took months.

The post The code came fast. Trust took months. appeared first on Dimitris Tonias.

The primary purpose of Trends is to reduce storage requirements and improve the performance of long-term data analysis and visualization. By storing trends, Zabbix allows users to maintain historical performance and status information over extended periods (months or even years) without overwhelming the database with detailed history records.

The message “Zabbix server: More than 75% used in the trends cache” from your Zabbix monitoring system indicates that the trends cache size is nearing or exceeding its configured maximum limit, which can impact performance.

This issue arises when the trends cache, which stores trend data before it is written to the database, fills up due to high data input rates or insufficient flushing.

As you can see in the graph below, the trends cache is reaching its maximum value, which is currently 4 MB.

How to fix high trends cache usage on the Zabbix server

After SSH into the Zabbix server, open the Zabbix configuration file with your favorite editor, like the Nano editor. You can typically find it in /etc/zabbix/zabbix_server.conf

sudo nano /etc/zabbix/zabbix_server.conf

Find the parameter TrendsCacheSize.

Change the size of Trends Cache to a greater value than the current one. In this case, I’m changing the value from 4 MB to 64 MB.

To apply the new TrendsCache size, you have to restart the zabbix-server service. Type the following command:

sudo systemctl restart zabbix-server

As you can see in the Trends Cache Usage graph below, after I restarted the server, the problem no longer exists.

As an extra precaution, you can view the graph of all of your Zabbix server caches, like the Configuration Cache, where we had a similar issue before, in the Zabbix Server Health Dashboard.

By taking these steps, you should manage the trends cache usage more effectively and keep your Zabbix server running smoothly.

The post Zabbix server: More than 75% used in the trends cache appeared first on Dimitris Tonias.

In this blog post, we will guide you through the simple steps to check the word count on Google Docs, whether you use a laptop or desktop computer or access the Google Docs app from your Android or iOS device.

So, at any time, you will know both the number of words you have typed and the number of characters and pages.

Let’s see how you can do this.

How to check Word Count on Google Docs

Check the word count on the web version of Google Docs

In an open Google Docs document, go to the Tools menu and then Word Count.

The window that will appear shows your document’s current settings. To display the word counts of your document, click on the Display word count while typing option and then on OK.

The word count you’ve typed so far will now appear in the lower-left corner of the document and will automatically update as you type.

By clicking on the ‘arrow,’ you can see even more metrics, such as the number of pages, characters, and non-space characters.

To hide the word count box, click the corresponding Hide word count option, as shown in the image above.

Unfortunately, this setting needs to be enabled every time you open a Google document, even if it’s the same document you already enabled. If you like shortcuts, combine Win+Shift+C on Windows or Command+Shift+C on macOS to toggle the show or hide switch in your document.

Check Google Docs word count on Android

Launch your Google Docs app on your Android smartphone or tablet and open the Google Doc you are working on.

Tap the three-dot menu in the upper right corner, then tap the Word count option.

You can view your document’s number of words, characters, and characters (excluding spaces).

Check Google Docs word count on iOS and iPadOS

Launch your Google Docs app on your iPhone or iPad and open the Google Doc you are working on.

Tap the three-dot menu in the upper right corner, then tap the Word count option.

You can view your document’s number of words, characters, and characters (excluding spaces).

Check Google Docs word count on selected text

Whether editing a document on Google Docs’s web version or the Android or iOS app, you can view the word count for just a portion of the document you want.

Select the text on Google Docs and follow the abovementioned steps for every case.

Understanding how Google Docs’ word count feature works can greatly enhance your writing, especially when precision is required for assignments, reports, or publications.

The post Check word count on Google Docs appeared first on Dimitris Tonias.

On my Zabbix server, I got the following alert (or problem): Zabbix server: More than 75% used in the configuration cache.

To get a more detailed graph, click on the problem and then click the Zabbix configuration cache, % used option.

As you can see (based on the time range you select), there is a continuous increase over the last day. Once the Configuration cache usage has gone beyond 75%, the trigger was activated automatically.

Don’t worry, this is a very common problem and we can fix it quite easily. What we have to do is edit the Zabbix server configuration file and change the CacheSize parameter.

How to fix high configuration cache usage on Zabbix server

You can find the configuration file in /etc/zabbix/zabbix_server.conf. Edit it with your favorite editor, I use Nano editor.

sudo nano /etc/zabbix/zabbix_server.conf

Find the CacheSize Option and change the parameter to something greater than the default value. Don’t forget to save the changes you just made. Note, the # sign indicates a comment on the file.

### Option: CacheSize
#       Size of configuration cache, in bytes.
#       Shared memory size for storing host, item and trigger data.
# Mandatory: no
# Range: 128K-64G
# Default:
CacheSize=256

For Zabbix 6.0+ the default CacheSize is 32M whereas in previous versions it was 8M. In my case, I changed it to 256M. The value is the size of the configuration cache, in bytes. The range you can choose is between 128K-64G.

To apply the new CacheSize value, you have to restart the zabbix-server service.

sudo systemctl restart zabbix-server

As you can see in the Zabbix Cache Usage graph, the problem is now resolved.

As a side note, you can view the graph of all your Zabbix server Cache Usage in the Zabbix Server Health Dashboard.

The post Zabbix server: More than 75% used in the configuration cache appeared first on Dimitris Tonias.

The approval of updates is an important asset for system administrators as they have the ability to approve updates on a small test portion of the infrastructure and if everything is working properly, then they will approve updates for the rest of the infrastructure. So, problems that may be encountered when installing updates can be addressed more timely and effectively. Well, such problems are a reality.

Typically, updates are accepted manually. The administrator spends time checking the available updates and then approves or rejects the updates that will be deployed to the clients. However, it is possible to automatically approve updates based on the rules you set.

Approve and deploy WSUS updates

After you open the WSUS Admin Console, click Updates. Here is a summary of the status of the updates. As you will see, the individual sections are separated into All Updates, Critical Updates, Security Updates, and WSUS Updates.

The approval of the updates, so that they are then passed to the clients, is done through these modules. In this case, we will see how to approve an update.

From the All Updates section, right-click an update, and then click Approve.

In the window that will appear, select for which computer groups the update should be approved by clicking Approve for Install. By default, All Computers is enabled, but you can approve the update for each group individually. This depends entirely on your own practices.

Then, the approval progress window appears with the corresponding success message. Click the Close button to close the window.

This is a typical case of approving updates manually so they can start deploying on WSUS clients.

In some cases, if you do not want to approve the updates manually, you can set auto-approval rules according to the settings you configure.

Configure auto-approval rules in WSUS 2016

In the WSUS Administration Console window, go to the Options category and click on Automatic Approvals.

In the window that appears, on the Update Rules tab, there is already a default rule named Default Automatic Approval Rule, which is disabled.

To create a new rule, click New Rule.

Here, the rule is configured in three steps. First, you select one or more of the properties of the updates, then the action that will take place (for example, approval) and finally you specify the name of the rule.

By clicking on each of the links with the blue color, its corresponding properties appear.

For example, you can enable automatic approval for all the security updates that will be available from now on for the computer groups you chose, as shown in the figure below.

Finally, on the Advanced tab you can set whether updates to the WSUS Server itself will be automatically approved and how update revisions will be approved. By default, these settings are turned on and you will want to keep them that way.

The post Approve updates in WSUS 2016 appeared first on Dimitris Tonias.

The most fundamental task is to direct each client to communicate with WSUS Server to check for new updates instead of using Microsoft Update over the Internet. Next, we will go through the individual settings for scheduling updates, configuring alerts, etc.

In general, these settings can be made through Group Policy, Local Policy, or Registry. However, as we refer to an Active Directory infrastructure, we will focus on WSUS policy settings through Group Policy.

In most cases, it is suggested to create a new Group Policy Object that will only apply to WSUS settings. You may use additional policies, such as when assigning clients to different computer groups.

The WSUS settings in the Group Policy Editor are located at:

Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Update

As shown in the picture, there are several policies. Of course, you do not have to enable all of them. In the following steps, we will only focus on the necessary policies you will need in order to establish communication between WSUS Server and clients as well as schedule update installation.

Beyond that, take some time to comprehend the other policies and enable what you think is important for your infrastructure. Microsoft, as always, has taken care to publish a fairly detailed article.

The most important policies for WSUS to work properly are:

• Configure Automatic Updates
• Specify intranet Microsoft update service location

Configure Automatic Updates

A necessary policy that enables the use of Automatic Updates on the client to install updates.

After you turn the switch to Enabled, select one of the four options depending on how much ‘freedom’ you will give the end user to install the updates.

Specify intranet Microsoft update service location

Another necessary policy in which you declare WSUS Server to be detected by clients. After you set the switch to Enabled, type the WSUS Server address in the two fields like http://servername.local:8530 as shown in the figure below.

Note: If the Configure Automatic Updates policy is disabled, then this policy is not applicable.

These are the two most important policies for WSUS Server. If you encounter a problem when setting it up initially, then take a look at these policies first.

Finally, do not forget to apply the policy to the OUs of the Active Directory infrastructure.

From now on, in the next few hours, customers will begin to appear in the computer groups of the WSUS administration console. As long as you have synchronized and approved the updates, it will begin installing the updates according to the policies you implemented through the Group Policy.

The post Configure Group Policy to deploy updates using WSUS 2016 appeared first on Dimitris Tonias.

Computer Groups are very important in a WSUS infrastructure, as you will be able to deploy only to the groups you want in a more methodical manner and then have the corresponding reports for each group separately.

By default, there are two computer groups, All Computers, and Unassigned Computers. When a client first communicates with the WSUS server, each client is added to the list of both these groups.

Create and manage computer groups

Besides the default groups, you can create as many computer groups as you think it is necessary to manage them more efficiently. The process is very simple.

Right-click All Computers, and then click Add Computer Group.

Enter the name of the group and click the Add button.

As shown in the above image, in my home lab I have created some groups based on the status of the individual client. How to separate your own groups and which clients will be included is at your own discretion.

Of course, in a productive environment, it’s a good idea to create a separate test group with some test clients to test the updates before deploying them across the infrastructure.

To transfer one or more clients to a computer group, right-click the client and then Change Membership.

In the window that appears, select the computer group and click OK.

If you do not see a client in the list, select Any from the Status drop-down menu and click Refresh.

This so easy to handle in a small infrastructure, you create the groups, move the clients where you want and you finished configuring them. But what if there are hundreds of clients and should be added to different groups? Can we automate this?

In this process, we use Client-side targeting. Using Group Policy, we can define in which Computer Groups each client will be assigned to, based on the client-side targeting setting that we set up in the GPO. Let’s look at it in practice.

Configure client-side targeting via Group Policy

Open the Group Policy administration console, create a new policy, and click Edit to configure it. Then browse to the followin path.

Computer Configuration – Policies – Administrative Templates – Windows Components – Windows Update

Here, find the policy named Enable client-side targeting and double click or edit to set it.

Click on Enabled and in the Target group name for this computer field, type the name of the group that will assigned on the WSUS console. You can type more names by separating them with a semicolon.

As the note in the description says, this policy works only if you have enabled the Specify intranet Microsoft service update location policy.

Note: You will first need to create computer groups on the WSUS server and then add the clients through the group policy.

So, by creating different policies with the corresponding computer groups and applying them to separate Active Directory OUs, you can bypass the above manual management of clients in groups. Also, if you add a new client to an OU in the future, then it will take the corresponding policies and updates from the WSUS server without having to do so through the WSUS administrative console.

Finally, whichever method you select for your infrastructure, you will also need to change the corresponding setting in the Options category of WSUS Server and specifically in the Computers section.

In the window that appears, select the client grouping method in Computer Groups and click OK.

The post Configure computer groups in WSUS 2016 appeared first on Dimitris Tonias.

Depending on the infrastructure, you may need some further action on your part to ensure WSUS server communication with clients with the upstream server (eg Microsoft Update).

For example, if there is a firewall between the WSUS server and the Internet, then they will need to be able to communicate with each other in order to check and get updates. The same applies if you are using proxy servers. You can read more here.

So, let’s move on to the initial WSUS settings using the Configuration Wizard.

WSUS 2016 Initial Configuration Settings

If you installed the role through Server Manager and kept the installation wizard window open, you can open the initial settings window by clicking Launch Post-Installation tasks as shown in the figure.

Alternatively, Server Manager alerts will display the corresponding message from where you can open the same window.

In the window that appears, tick Store updates locally, select the folder where the updates will be stored, and click the Run button to continue.

The Configuration Wizard for WSUS Server will open, where you will need to choose which updates WSUS will receive, which languages, the timing of synchronization, etc. Of course, all settings can be changed at any time based on your needs.

In the Before You Begin section, simply click Next to continue.

In the Microsoft Update Improvement Program section, select whether to participate in the Microsoft program by choosing the appropriate option and then click Next to continue.

In the Choose Upstream Server section, select which server will synchronize the WSUS server. If it is your first WSUS server then select Synchronize from Microsoft Update. If WSUS acts as a replica server then select Synchronize from another Windows Server Update Services server and fill in the necessary information for successful connection to each other. Click Next to continue.

In the Specify Proxy Server section, fill in the corresponding fields as long as you are using a proxy server on your infrastructure, otherwise simply bypass this step by clicking Next to continue.

Based on the settings you selected in the previous two steps, you will be prompted to make a connection to the upstream server to save the settings. Click on the Start Connecting button and wait until the process completes, which may take several minutes.

In the Choose Languages ​​section, enable Download update only in these languages ​​and select only the languages ​​you use on your infrastructure. For example, if you have a mix of Windows versions in Greek and English, select only Greek and English. Click Next to continue.

In the Choose Products section, first browse the entire list and select only the products you use on your infrastructure and you want to receive all available updates. If you do it for the first time, it would be best to select only a few products and then familiarize yourself with the WSUS environment to add even more products. Click Next to continue.

In the Choose Classifications section, select only the update categories you are interested in depending on the products you selected in the previous step. Of course, check these with caution. For example, I would not activate the Drivers option because the result would be tens or hundreds of GB updates that 99% of these would not be used on the infrastructure.

In the Configure Sync Schedule section, select whether synchronization to check for new updates will be done manually or automatically according to the schedule you set. Obviously, it is advisable to do so automatically when the infrastructure is not running in full engines, such as the after hours when employees are not working.

In the Finished section, the configuration process of the original WSUS server settings has been completed. What’s left now is to make the initial synchronization to detect all available updates from the upstream server (eg Microsoft Update) and then start downloading them. By selecting Begin initial synchronization and clicking Finish this will be done immediately.

However, you can skip this step for the time being, and schedule the synchronization to a more ‘free’ time as the network will be tasked with receiving tens of GB of updates. You can also start the original synchronization manually through the WSUS management console.

The duration of the initial synchronization can take from a few minutes to several hours. This depends directly on the number of products and categories you chose in the previous steps.

The post The initial configuration of WSUS 2016 appeared first on Dimitris Tonias.

Before you start designing and installing WSUS on Windows Server 2016, you should take a look at the minimum requirements that your infrastructure needs to meet.

Install Windows Server Update Services (WSUS)

After you open Server Manager, click Manage and then Add Roles and Features.

In the Before You Begin section, click Next to continue.

In the Installation Type section, select Role-based or feature-based installation and click Next to continue.

In the Server Selection section, select Select a server from the server pool, and then the server to install the role. Click Next to continue.

Under Server Roles, select Windows Server Update Services. In the window that appears, click the Add Features button while you have ticked Include management tools, and then click Next to continue.

In the Features section, you do not have to choose anything, click Next to continue.

In the WSUS section, click Next to continue.

In the Role Services subsection, select the WID Connectivity and WSUS Services options and click Next to continue. WID (Windows Internal Database) means that an internal database will be created on the machine. This is the proposed regulation for the majority of cases of small and medium-sized enterprises. For larger installations using SQL Server, enable the SQL Server Connectivity option.

In the Content sub-section, enable the Store update option in the following location option, and then type the location (local or network) to store the system updates. Make sure you have enough GB of free disk space to report. Click Next to continue.

In the Web Server Role (IIS) section, click Next to continue.

In the Role Services subsection, all necessary services are already pre-defined. Click Next to continue.

In the Confirmation section, take a look at the features to be installed and click the Install button to start the process.

Then, in the Results section, you will see the progress of the installation. You can leave the window open or close it, the installation will be completed regardless of your choice.

At this point, WSUS is installed on Windows Server 2016. However, this was the first step. You will need now to complete the WSUS configuration wizard to enable WSUS.

The post Install WSUS in Windows Server 2016 appeared first on Dimitris Tonias.

There are 9 predefined WSUS reports and can be found in the Reports section of the WSUS Management Console.

However, the first time that you click on a report you’ll get the following message.

Feature Unavailable. The Microsoft Report Viewer 2012 Redistributable is required for this feature. Please close the console before installing this package.

As shown in the picture, there is a link to the message that links you to this page to download Microsoft Report Viewer 2012 Runtime.

Running the ReportViewer.msi that you just downloaded, another message appears.

Setup is missing an installation prerequisite: Microsoft System CLR Types for SQL Server 2012

Ah, the struggle is real. But we keep going.

Performing a google search, one of the first results is this Microsoft download page. Once the page opens, you will be prompted to download a .txt file. This file contains a message from Microsoft that tells us to look at the links in the Install Instructions section to find the component that we want to download.

Finally, just below the middle of the page, you will find Microsoft System CLR Types for Microsoft SQL Server 2012 that contains the links for downloading the component for 32-bit and 64-bit architecture. For your convenience, I quote here these two direct links.

x86 Package
x64 Package

Next, install the component.

Then proceed to install ReportViewer.msi that you downloaded earlier.

That was, the frustration is over. Now you can open the WSUS administrative console and run any report you want.

The post Error opening Report Viewer on WSUS 2016 appeared first on Dimitris Tonias.