IT Admin Tips: Deploying CCleaner Across Your Network

Working in the IT field, you've probably ran across at least one situation where you've had to "clean" your PC by clearing out temporary files and system caches. There are numerous tools that can make this task extremely easy to perform, one being CCleaner by Piriform. It's a great tool for running on your own PC, but running it across an entire corporation can be a daunting task... unless you've purchased the CCleaner Network Edition or higher.

Have no fear though. In just a short amount of time, you can configure CCleaner, silently install it, and then run it across your entire home workgroup or corporate network. Before you can begin, however, you will need to install CCleaner onto your own PC. This is a very straightforward installation, thus will not be covered in this article.

With CCleaner installed, you will first need to open a Command Prompt terminal and navigate to its installation directory. From here, you will need to run the following command:

CCleaner.exe /export

Running this command will create three files within the CCleaner directory:

- winapp.ini
- winreg.ini
- winsys.ini

Now you will need to rename each of the files to the following: "winapp1.ini", "winreg1.ini" and "winsys1.ini". This will allow you to configure the desired cleaning settings for CCleaner, which you will be able to deploy across your network.

Feel free to edit the INI files to fit your desired needs. Piriform themselves have some decent documentation on how to use the INI files. It is, however, just as easy to play around with the files yourself by editing and/or deleting entries. I, personally, have slimmed down the INI files by removing entries that do not apply to my setup, along with focusing mostly on cleaning browser files. Again, everyone will have different requirements and/or preferences on this.

After tweaking the settings for CCleaner, you can begin silently deploying it across your network. For my example, I will be using the CCleaner "Slim" edition. This particular version does not include the toolbar that is included with the standard installer. Also, as not everyone has a software deployment solution in place, we will be using a network share to store the install/config files and a BATCH script for the installation itself.

Ensure that everyone has, at a minimum, Read access to the folder within the network share where you have places the files. After doing so, you will need to run something similar to the following BATCH script on every desired PC (Logon Scripts are a great and easy way to do this):

@ECHO OFF
SETLOCAL
PUSHD \\NETWORKSHARE\CCleaner_Install
SET DRIVE=%CD%
SET DRIVE=%DRIVE:\=%
CD /d C:\
%DRIVE%\CCSetup_Slim.exe /S /D=C:\IT_Tools\CCleaner
NET USE %DRIVE% /delete /y
IF EXIST "C:\Documents and Settings\All Users\Start Menu\Programs\CCleaner" (
     RD /S /Q "C:\Documents and Settings\All Users\Start Menu\Programs\CCleaner"
     )
IF EXIST "C:\Documents and Settings\All Users\Desktop\CCleaner.lnk" (
     DEL /F /Q "C:\Documents and Settings\All Users\Desktop\CCleaner.lnk"
     )

IF EXIST "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CCleaner" (
     RD /S /Q "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CCleaner"
     )

IF EXIST "C:\Users\Public\Desktop\CCleaner.lnk" (
     DEL /F /Q "C:\Users\Public\Desktop\CCleaner.lnk"
     )
XCOPY %DRIVE%\*.INI C:\IT_Tools\CCleaner /Q
ENDLOCAL

This particular script will map the network share to an unused drive letter on the PC, then install CCleaner to the C:\IT_Tools\CCleaner directory. After installing CCleaner, the Start Menu and Desktop shortcuts will be deleted, and the INI files will be copied to the newly created CCleaner directory. After the deployment is complete, the mapped drive will be removed from the PC.

Once you have deployed CCleaner to your network PCs, you can easily run a silent scan/clean using the following command. This can be placed into a Logon Script, or added as a Scheduled Task.

C:\IT_Tools_CCleaner\CCleaner.exe /AUTO

There you have it. You should now be able to run CCleaner across your entire network, whether it be a home network or a corporate domain.

Read More

SAP Admin Tips: Configuring SAP Installation Server Packages

If you followed the steps outlined in my last post, you should now have an SAP Installation Server configured. With that out of the way, you can now create your own custom SAPGUI package to deploy to users in your environment.

By creating your own custom SAPGUI packages, you will be able to include ONLY the features that are relevant to your SAP environment. Doing this can significantly reduce the size of the SAPGUI installation file, along with the time it takes to install the application. If you were to pair a "slimmed-down" SAPGUI installer with something like a logon script, you could deploy the latest version of SAPGUI across your network in a much shorter time span.

In order to create a custom package, you will first need to open up the SAP Installation Server Administration application. If you have forgotten where this is located, you can navigate to the shared directory used during the installation and then to Setup -> NwSapSetupAdmin.exe. I would recommend creating a shortcut to the application for future use.

After launching the administration tool, click on New Package from the top menu.

Click New Package in order to launch the package creation process.
From the initial splash screen, click Next to begin.

You should now see a list of available features which you can add to your package.

Available features to be added to your custom package.
For my example, I have selected only the features that would make up a somewhat "bare-bones" SAPGUI install.

This selection should provide only the basic features necessary for end users.
On the following screen, you will be required to provide a name for your package.

Your package name should reflect the configuration you have provided.
Now you will need to provide a command line name for your package. This is what will be used during the installation of the package.

For easiest installation in a Windows environment, it is recommended to refrain from adding spaces to your command line name.
You should now be finished with your custom package! You can now deploy the package using the Silent Installation Command Line parameters provided under the package's properties, or insert some VBScript into it for even more customization.

Read More

SAP Admin Tips: Initial Setup of the SAP Installation Server

In the event that you need to install the SAPGUI client on numerous computers, SAP has provided the SAP Installation Server. This system allows you to perform new installations of the SAPGUI client, upgrade current users to a latest version, apply patches, and much more. The SAP Installation Server was designed to make centralized administration of SAPGUI clients not only possible, but easy.

Installation of the SAP Installation Server is fairly straightforward, and can be accomplished through the following outlined steps.

I. Download the Necessary Files
1. Log into the SAP Portal Download Center. This will require that you have an SAP S-ID.
2. Navigate to the Download Catalog -> SAP Frontend Components -> SAP GUI for windows -> SAP GUI FOR WINDOWS 7.30 CORE -> Installation -> Downloads
3. Download and extract both zip files using the Download Basket.

II. Beginning the Installation
1. After the zip files have been successfully downloaded, and their contents extracted, open up the first of the two files (typically ends with "_6").
2. Navigate to NW_7.0_Presentation_ -> PRES1 -> GUI -> WINDOWS -> WIN32 -> Setup
3. Run the file, NwCreateInstServer.exe. You may need to right-click the file, and select Run as administrator in order to ensure a proper installation.

III. Installing the SAP Installation Server
1. On the installation's initial splash page, click Next.
2. On this screen, you will need to select a shared network folder from which you will deploy SAPGUI installations from. If you need assistance with creating a shared folder, Microsoft has a simple walkthrough on it.

Browsing for a shared folder.
3. Click Next once your shared folder has been verified.
4. On this next screen, click Next again to begin the installation of the SAP Installation Server.

Installation of the SAP Installation Server.
5. After the installation is complete, click Close. This should launch the SAP Installation Administration Tool.

Initial launch of the SAP Installation Administration Tool.

In order for users to be able to install SAPGUI from the installation server without needing administrative privileges, you will need to configure Local Security Handling. This can be accomplished by performing the following tasks.

1. Click Services, and select Configure Local Security Handling.

Configuring Local Security Handling.
2. Click Next on the initial splash screen.
3. You will need to provide a domain account that will have administrative privileges on the workstations that will be installing SAPGUI. If you need assistance, Microsoft has provided documentation on how to add a domain account as a local administrator for all domain workstations.

Creating the Distribution Service Account.
4. Click Next, and then provide the domain account that will function as the Installation Service account. To make things easier, you can use the same domain account as you did in the previous step.
5. Once this has been completed, you can continue to the next step. If everything was successful you should see the following screen.

LSH has been successfully configured.

Now that you have successfully installation the SAP Installation Server, you can begin deploying the SAPGUI client to your remote workstations. Tune in for Part 2, where I will go over package configuration.

Read More

SAP Admin Tips: SAP Security Patching

Throughout the year, SAP releases numerous security patches and updates. For some security administrators this means that they will need to make time to implement these updates into their own system; however, this task tends to be overlooked by many. If you've never performed a security update to SAP, or would just like to audit your system's security patches, the task is very simple and can be performed in a few short steps.

In order to check your security system, you will need to run SAP Report RSECNOTE. This can be done via transaction ST13.

Executing the RSECNOTE report via ST13.

Once you have executed the report, you should see a list of security patches that your system is missing. These are color coded based off of severity, red being the most critical. Each security patch will have a corresponding OSS Note that should be applied to the system in order to alleviate that particular security risk.

RSECNOTE security patch results.

Performing a security patch to your SAP system should not affect your business operations, as it will not cause a lock within the system. It should also not have any adverse effects to your transactions and/or programs, unless they happened to have a security risk that was patched during the update. All in all, it should become a common practice to periodically check this report for any available security updates, and to resolve any issues.

Read More

SAP Admin Tips: Disabling NWBC Splash Screen

When launching the NetWeaver Business Client from within SAP, it firsts takes you to a splash screen. This screen shows all of the SAP Roles you have assigned via the cockpit. This isn't always useful, and from my experience can be more of a nuisance as it provides an unnecessary step when wanting to access NWBC. If you're like me, then you'd prefer to not have this splash screen anymore. Like a wide variety of things within SAP, it's not that hard to change if you just know where to look.

Screenshot of the NWBC Splash Screen.

The first thing you will need to do is run transaction SICF. This will let you manage the various services that SAP has available. The service that governs the splash screen is NWBC_LAUNCH.

From the starting screen of SICF, enter "*nwbc_launch" into the Service Name field and hit the Execute button.

SICF starting screen, with NWBC_LAUNCH service selected.

Executing this should bring you to a more detailed screen showing the NWBC_LAUNCH service. In order to remove the splash screen, you will need to right-click on the service and select Deactivate Service.

Screenshot showing the SICF screen after execution. Right-Click on the NWBC_LAUNCH service to deactivate it.

After performing these steps to deactivate NWBC_LAUNCH, you will no longer see the NWBC splash screen when accessing the Netweaver Business Client from within SAP. From now on you will be taken directly into the NWBC application.

Read More

IT Admin Tips: Exchange ActiveSync Device Reporting (through PowerShell)

If your corporate network happens to have Exchange 2010, chances are you may have employees with corporate email on their mobile devices. Exchange allows you to connect various mobile devices, whether tablets or smartphones, by way of Exchange ActiveSync (EAS). These devices may be part of a BYOD policy, or they may be provided by the company itself. In either event, you've got them tied to your Exchange server and as a Server Administrator, there may be a time where you need to report on what devices are currently synced.

Thankfully, with the installation of Exchange 2010 you will have access to a myriad of administrative tools, including numerous PowerShell cmdlets that can be ran through the Exchange Management Shell. You can find a complete list of cmdlets provided with Exchange 2010 on Microsoft's Technet page. One in particular is extremely useful in the task of reporting on ActiveSync devices, Get-ActiveSyncDevice.

Running this cmdlet as-is will provide you with an abundance of data in a not-so-user-friendly manner... so what do you do? If you've ever used PowerShell before, then you've probably used pipes to send the results of one cmdlet to another. This is very useful when you need to provide "cleaner" reports that include only the data you need, organized just the way you want it.

For example, let's take the output from Get-ActiveSyncDevice and pipe it into the Select-Object cmdlet in order to list only the objects we want to report on. So now we have:

Get-ActiveSyncDevice | Select-Object DeviceModel,FriendlyName,DeviceOS,UserDisplayName

This will now limit the data we will see for each ActiveSync device, but could still use some work to make it viewable within the PowerShell terminal. Let's pipe these results into the cmdlet Format-Table in order to size the table of data to the size of the PowerShell terminal:

Get-ActiveSyncDevice | Select-Object DeviceModel,FriendlyName,DeviceOS,UserDisplayName | FT -autosize -wrap

This should be much better than the original running of Get-ActiveSyncDevice, but let's say you want to sort the resulting data alphabetically by the DeviceModel object. To do this we'll add the Sort-Object cmdlet into the mix:

Get-ActiveSyncDevice | Select-Object DeviceModel,FriendlyName,DeviceOS,UserDisplayName | Sort-Object DeviceModel | FT -autosize -wrap

Now you should have the data you need, formatted just the way you want it. The only issue, it's still only viewable from within the PowerShell terminal. What if you want all of this formatted data in an Excel spreadsheet? PowerShell once again provides a way to do this, by way of yet another cmdlet. Let's replace the Format-Table cmdlet with Export-CSV to do this:

Get-ActiveSyncDevice | Select-Object DeviceModel,FriendlyName,DeviceOS,UserDisplayName | Sort-Object DeviceModel | Export-CSV -Path C:\ActiveSync-Devices.csv -NoTypeInformation

There you go! A well-formatted Excel spreadsheet containing all of the ActiveSync devices tied to your Exchange server.

Read More

SAP Admin Tips: How to "Unrelease" a Released Transport

So, you've been working on a few transports within your Development system and now it's time to release them for Import. You select a transport and click to release it, only then realizing that you've selected the wrong one. You've just released a transport, or sub-transport, that wasn't ready. Maybe you still needed to add more to it, or maybe it wasn't configured correctly. Either way, an "unrelease" button could be really useful right now. What do you do?

Screenshot of a released transport and sub-transport.

Thankfully, there is a solution for this that does exactly what you need. By running a single program, you will be able to change the transport's settings so that it will be once again modifiable.

First thing's first, as you are going to be executing an SAP program you will need to run transaction SE38. From here, you will input the program RDDIT076 and execute it.


Executing RDDIT076 from SE38.

When you first run this program, it will prompt you for the Request/Task. Input the Transport Request's ID that you wish to "unrelease" and click to execute. You should now see the transport, along with any sub-transports, and their corresponding settings. Having a status of "R" indicates that the transport is currently in a released state.

Screenshot of RDDIT076 overview.

Double-clicking on one of the transports will bring up a pop-up windows displaying its current settings.

Displaying transport request settings.

In order to edit these settings, you will need to either click the Display <-> Change button, or hit F9 on your keyboard. After entering Edit Mode, change the Status of the transport to the value "D".

Screenshot of changing the transport request's status.

After saving your changes, you should now see them reflected within the RDDIT076 overview screen.

Transport Request status now Modifiable (D).

You have now successfully unreleased a released SAP Transport Request. You can now make any necessary changes to them without issue.

Read More

SAP Admin Tips: SAP GUI Application Security

There are many methods from which you can access an SAP Application Server, but one of the more widely used applications is the SAP GUI client. This client is typically installed directly onto an end user's PC, and then configured in order to provide connectivity to each of the SAP systems a company may have in place (i.e. Development, Quality Assurance, Production, etc.).

Despite its widespread use, SAP GUI is not the most secure client "out of the box."

By default, the data transfer between the SAP GUI client and the SAP Application Server is compressed using the standard Huffman encoding compression algorithm. If you were to perform a packet capture of the data being transferred, it would appear to be illegible to read; however, it is not secured. In order to better understand this, you will need to know the difference between compression and encryption.

Data compression is a method of modifying the data being transferred in order to reduce the overall size of it. It also reduces the network bandwidth used during the data transfer. Data that has been compressed, must be decompressed once it has reached its destination in order to be used. If the data were to be compromised, it could be decompressed by an attacker so long as they know the compression algorithm used.

Data encryption is a method of modifying data in order to keep its contents secret. Once encrypted data reaches its destination, it must be decrypted before use. Unlike with decompression, merely knowing the algorithm used will not allow you to be able to view the data. Decryption requires a special key, known only to both members of the communication.

In its default state, it would be trivial for an attacker to decompress the data being transferred between SAP GUI and the SAP Application Server. Once the data has been compromised, the attacker would be able to view the entirety of the data transfer including:
    - Any UserID/Password entered into the system
    - Any transaction executed by the user
    - Any corporate data entered into the system

The image above shows the data transfer created during a user’s logon to the SAP Application Server after the compression has been removed. As you can see, the userid “testuser” is authenticating with the password “thisismypassword.”

In order to secure connections between SAP system components, the SAP interface for Secure Network Communications (SNC) must be used.

SNC offers the following protection to the communication:
    - Authentication
     Both the client and the server are always authenticated to each other.
    - Data Integrity
     The data transferred between the client and the server is protected so that if there is any manipulation of the data it will be detected.
    - Data Privacy
     The data transfer will now be encrypted, providing privacy protection. An attacker will not be able to access the data contained within it.

Read More

SAP Admin Tips: How to Implement CUA

One of the drawbacks of SAP that I have ran into is due to the numerous amount of clients you can create across multiple systems. This can result in users having multiple accounts for you to manage. Thankfully, there is a solution to this. Enter Central User Administration, aka CUA.

The necessary steps required to implement CUA are, fortunately, not very difficult assuming you have proper authorizations to the systems.

I. Specify Logical Systems
1. Log into the SAP client that will be the Central System.
2. Run transaction BD54.
3. Create new Logical System names for every client that will be part of CUA (Central and all Children) using the following naming convention:
    [System ID]CLNT[Client]
    Example: ITDCLNT100
4. In each Child System, add a Logical System name for the Central System using the method specified above.


II. Assign Logical Systems to Client
For each client that will be part of CUA, perform the following steps:
    1. Run transaction SCC4
    2. Switch to Change mode
    3. Double-click on the client for Details
    4. Specify the Logical System name


III. Create System Users
A.) In the Central System, create the following user:
    UserID: CUA_[System ID]
    Roles Assigned:
        - SAP_BC_USR_CUA_SETUP_CENTRAL
        - SAP_BC_USR_CUA_CENTRAL
        - SAP_BC_USR_CUA_CENTRAL_BDIST
B.) In each Child System, create the following user:
    UserID: CUA_[System ID]_[Client]
    Roles Assigned:
        - SAP_BC_USR_CUA_SETUP_CLIENT
        - SAP_BC_USR_CUA_CLIENT


IV. Create RFC Destinations
1. Log into the Central System.
2. Run transaction SM59.
3. For each Child System, create a new RFC Connection with settings similar to the following:



4. Ensure that the User under Logon & Security is the account you create in Step III-A for the Child System.
5. In each Child System, create an RFC Connection back to the Central System.


V. Create CUA
1. Log into the Central System.
2. Run transaction SCUA.
3. Enter the name of your distribution model, such as “CUA.”
4. Choose Create.
5. Enter the name of the Child Systems.
6. Save.


VI. Synchronization of Company Addresses
1. Log into the Central System.
2. Run transaction SCUG.
3. Right-click on the first Child System and choose to Synchronize Company Addresses, repeat for each Child System.
4. From the main screen of SCUG, click the Company Addresses button to distribute them to target systems.


VII. Transfer Users
1. Log into the Central System.
2. Run transaction SCUG.
3. Right-click on the Central System and choose to Transfer Users.
4. Select all New and Changed users and choose Transfer Users.
5. Repeat for each Child System.


VIII. Create Partner Profile for Logical System
For each Child System, perform the following steps:
    1. Run transaction WE20.
    2. Create a new Partner Profile under the Logical System (LS) category with settings similar to the following:



    3. Define the following Inbound Parameters:
        Message Type: USERCLONE
        Process Code: BAPP


Once you have all of these steps complete, you should be able to perform all user administration from your Central System. Within transaction SU01 you will have a new tab called Systems which will allow you to give a user access to any system within CUA. You will also be able to assign Roles per system. For example, a user could have SAP_ALL within your Development system and Display Only within your Production system, all managed through your Central System. No more logging into each individual system for user administration.

Read More

SAP Admin Tips: How to Create a Copy of a Standard SAP Transaction

There may come a time within SAP where you will need to create a copy of a standard transaction in order to customize it to your specifications. Surprisingly, making a copy of a transaction is not as difficult as one may imagine.

Note: You may need to create your own Package to store these changes into. If you do not, then you may be able to choose "Local Object" when prompted.

The first thing you will need to do is determine what underlying program is called from the transaction you wish to create a copy of. This can easily be done by running transaction SE93, imputing the desired transaction (OS01 in my case), and clicking Display.

Note: It may be best to either screenshot or document the settings displayed for the transaction. Make sure you also click on the 'Values' button in order to get the Authorization Object's required values.

Now that you know what the program's name is, RSHOST14 in our case, you can go to transaction SE80 in order to access the ABAP Workbench. From the initial screen, you will need to select "Program" from within the drop-down and then type the program name within the text field. Click the Display button (glasses) in order to view the program.

Now that the object data is shown for the program, you can right-click on it and select "Copy" from the available list of options.

Ensure that the source program is correct and then enter the name you wish to use for the new transaction (starting with a "Z").

From the next screen, select all of the elements you wish to copy over to the new transaction. In this case, I have selected everything.

At this point, you may be prompted to add this object to a Package. You can either use one that you have created, or you can try to use "Local Object."

Now that we have a successful copy of the original program, we will need to assign a transaction to it. Remember that transactions merely call underlying programs. To do this, you can right-click on the new program's name, hover over the "Create" option, and select "Transaction" from the list.

Now you will be able to give your new transaction a proper name and give it a descriptive short text. You will also need to select how you want it to start. For this particular program, you will need to select "Program and selection screen."

We're almost done with this. Remember the program data I told you to screenshot or document? Now we need it.

On the final screen, you will need to fill out each and every field similarly to how the original program data was. The following image shows what was required for a copy of OS01.

All that's left now is to right-click on the program and select "Activate," activating all of the objects within it. Once you're done, click Save.

If everything went smoothly, you should now be able to run your new transaction and see an identical screen to the original.

Good luck and have fun!

Read More

SAP Admin Tips: How to Enable Save Layout Option within VA05

Like so many SAP transactions, VA05 provides users with the ability to change the current layout of the list they are viewing. The only issue? The option to save the layout is "grayed out" by default.

Note: The above image reflects the available options even if the user has SAP_ALL, SAP_NEW, or access to S_ALV_LAYO.

Thankfully, fixing this issue is fairly simple and does not require assigning the user with access to Authorization Object S_ALV_LAYO (Provides access to change layouts globally, and should never be assigned to End Users).

In order to do so, you will need to assign a parameter to the user's profile. This can be done from within SU01 if you are an administrator, or SU3 if you are the end user. The available parameter values are as follows:

* SD_VARIANT_MAINTAIN "A" - Can be changed throughout the system.
* SD_VARIANT_MAINTAIN "U" - Can be changed at the user level.

For security purposes, users should be locked down to user level changes only.

After saving the changes, the user can log back into the system and run VA05. Now they should have the option to save their layouts.

As you can see in the following image, they will be locked down to User-specific changes only.

There you have it. Like I said in the beginning, this is a fairly quick and easy resolution.

Read More